Hello!
I’ve spent a lot of time struggling with Hetzner’s KVM console, there are a lot of problems causing severe issues with setting up passwords and passphrases. I just thought I’d create this “guide” to get things rolling, for everyone who faces the same issues I’ve faced.
Step 1 - Firewall
Set up a firewall and only open port 22 with your IP (you can look it up using ip.me).
Step 2 - Installation
Perform the installation procedure as normal, setting very simple passwords and passphrases for the user accounts and the disk encryption. Set them to something like 123. These will be changed later!
I’m using Debian 13, the steps may or may not be the same for your choice of distribution.
Step 3 - SSH access
Unmount the ISO and reboot. Enter the console again, log in as root with your simple password. Now, if you have the same problem as me, keys like /, CTRL etc. won’t work, so I used tab completion and vi to to modify the config file.
# cd ../etc/ssh/
# vi sshd<TAB>
Inside vi, press o to create a new line and enter insert mode. Add:
PermitRootLogin yes
PasswordAuthentication yes
Press ESC and then <SHIFT>-yy (so holding shift and pressing y twice). This will save the file and exit vi. Restart the SSH services:
# systemctl restart ssh sshd
Step 4 - Dropbear
ssh into your VPS. Now you have full keyboard access like usual. Install dropbear-initramfs, which is an SSH server that’s placed in the initial RAM filesystem so that you can ssh into your VPS during start up so you can easily enter your encryption passphrase.
Generate a new key pair and add the public key to /etc/dropbear/initramfs/authorized_keys
Run update-initramfs -u and reboot. You should now be able to ssh into your VPS using the key you just generated. The following command lets you unlock the encrypted disk:
cryptroot-unlock
This will probably disconnect you from the tunnel, simply re-establish the SSH tunnel again.
Step 5 - Changing passwords and passphrases
To change the encryption passphrase:
# cryptsetup luksAddKey /dev/sdXY
# cryptsetup luksRemoveKey
Lock the root user and change the password of your user (don’t forget to add the user to the sudo group!):
# passwd -l root
# passwd user
Done!
At this point you might want to use some other means to access the server, such as Netbird or Tailscale or Wireguard. Regardless of how you decide to access the server, you should revert the changes to sshd_config.
P.S.
I have no idea if this is a secure or good way to do this. Use at your own risk!
You must log in or register to comment.
Enabling SSH password authentication is unnecessary and not a good idea, especially if your temporary passwords are simple. I haven’t used Hetzner but there is probably a way to upload a file or to paste into the console, or else if you fix your keyboard you could at least type a URL to download the public key from the internet. You may want to look into cloud-init instead of manually installing and configuring your VMs.
LUKS may not make your server meaningfully more secure. Anyone who can snapshot your server while it’s running or modify your unencrypted kernel or initrd files before you next unlock the server will be able to access your files.
Why full disk encryption is important: what happens when you switch servers or providers: can you be sure the disk gets wiped properly?
Or when your disk dies and gets replaced, what happens to the old disk? Will they physically destroy it or just throw it in the bin?
When encrypted, it doesn’t matter; no one will get data off of them. That’s why you encrypt servers.
It’s worth going through the provider’s policies.
For example, here’s how Hetzner handles deletion of your data
Encryption will prevent mistakes, but if you can’t trust the provider’s policies you shouldn’t trust them to run your infrastructure at all.
Security is always applied in layers. The more the better. There’s a reason “encryption at rest” is a requirement in many audits.
Enabling SSH password authentication is unnecessary and not a good idea, especially if your temporary passwords are simple.
Noted, thank you!
I haven’t used Hetzner but there is probably a way to upload a file or to paste into the console
Pasting generates garbled text, with letters and symbols being replaced or simply missing. I haven’t found a way to upload a file, nor have I found a solution to the issues in general. I found a few threads on Reddit complaining about the same thing, but no one had found a solution. It just seems to be an issue with the way Hetzner has set up their KVM console.
There is a way to upload custom ISO files, but it’s quite annoying as you have to open a ticket with a direct link to the ISO and wait for the staff to upload it for you to the UI.
You may want to look into cloud-init instead of manually installing and configuring your VMs.
Thank you! I’ll check it out.
LUKS may not make your server meaningfully more secure. Anyone who can snapshot your server while it’s running or modify your unencrypted kernel or initrd files before you next unlock the server will be able to access your files.
That’s true. It’s mostly just to prevent data recovery should the VPS be recycled for services that don’t support E2EE, like Immich. I thought it would be better than nothing.
Am I the only one using a random 5 digit port for ssh? Why using the default port 22? It’s just saving time for an attacker.
To me, the nonstandard port is mostly nice for reducing log spam from scripts. The risk is that using a nonstandard port lulls one into a false sense of security and overlook good sshd practices. Good sshd practices will prevent the script-kiddies just as well as the non-standard port, while a non-standard port will not challenge a targeted attack. And, if you interact with multiple servers, it can be inconvenient to remember a different port for each one.
Still better than nothing.
But there is also a possibility to dump the RAM and recover a key or data.If you can, store only pre-encrypted data.
If I can use E2EE, I will. This VPS will never be exposed to the internet, it will only be accessible through Netbird. The main reason for setting up FDE is for Immich which doesn’t support E2EE, so that the data won’t be (as easily) recoverable should the VPS be recycled. But yeah, it’s not perfect, but like you said it’s better than nothing.
I don’t really take physical access (including Hetzner and law enforcement) into account in my threat model.
