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.
Why not cloudinit instead of ssh?
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters DHCP Dynamic Host Configuration Protocol, automates assignment of IPs when connecting to a network IP Internet Protocol SSH Secure Shell for remote terminal access VPN Virtual Private Network VPS Virtual Private Server (opposed to shared hosting)
5 acronyms in this thread; the most compressed thread commented on today has 9 acronyms.
[Thread #151 for this comm, first seen 9th Mar 2026, 14:00] [FAQ] [Full list] [Contact] [Source code]
I’ve had a similar issue with / and some special keys. Numpad solved the / problem, using the system through SSH allows properly using your keyboard, and I’d imagine keybinds such as Gaomon’s or AntimicroX’s could be used too.
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.
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.
This is a little oversimplified. Hardware vendors have done a lot of work in the last 10-20 years to make it hard to impossible to obtain data this way. AMD-SEV for example.
There are other more realistic attacks like simply etrackt the ssh server signature and MITM the ssh connection and extract the LUKS password.
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.
Agreed. I was going to argue more against encryption, but you can see me somewhat changing my mind in the second half of my comment.
For me personally, I don’t want the hassle of encryption on my VPS and have decided I’m fine with the remaining risk.
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.
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.
Set up a firewall and only open port 22 with your IP (you can look it up using ip.me).
I keep wondering about this part whenever I read it. Do y’all have static IP addresses so you can do this easily? If I did this, I’d probably lock myself out within a week (which is roughly the interval at which my public IPv4 will change).
This is only supposed to be temporary while you set up the FDE, your IP is unlikely to change in the 30 minutes or so it takes to go through these steps.
In any other scenario I’d close port 22 and use a mesh VPN with SSH capabilities, like Netbird or Tailscale. I’d only open it up again to access Dropbear during reboots, and I’d use IP filtering for that as well.
As for DHCP, I guess it depends on the ISP. I don’t have a static IP but mine doesn’t change as far as I can tell unless my router is disconnected for a longer while.
Now I get it. Thanks for the explanation!
This post is about a hetzner host so I would assume it’s static
use ddns or similar to keep track of tour IP?
Sure, that’s what I do for hosting my stuff. DDNS does not help with SSH whitelisting because that is IP-based, not based on a URL.
Stupid me, missed the IP whitelisting part.
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.
I use nonstandard ports for just about everything such as Docker containers, including ssh. However, modern bots are quite capable of scanning your server for vulnerabilities, CVE, zero day, and SSH. A non standard SSH port does reduce noise a bit but isn’t a reliable defense against scanners.
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.
The whole port range can be scanned in under a second. A real attack does not care if your ssh port is 22 or 69420. Changing Port is just snake oil.
It can be scanned, but definitely not under a second.
Yes, it is called multithreading. Just one example: https://github.com/BrandonBerne/masscan
