Hello!

I’ve spent a lot of time struggling with Hetzner’s KVM console, there are a lot of problems causing severe issues with settings 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.

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!

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.

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.

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.

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.

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.

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.

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.

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.

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).

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

[Thread #151 for this comm, first seen 9th Mar 2026, 14:00] [FAQ] [Full list] [Contact] [Source code]

use ddns or similar to keep track of tour IP?

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.

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.

This post is about a hetzner host so I would assume it’s static

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!

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.

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.

Why not cloudinit instead of ssh?

It can be scanned, but definitely not under a second.

Yes, it is called multithreading. Just one example: https://github.com/BrandonBerne/masscan

They might care if it’s 69420 since the max port number is 2^16 = 65536

You can fire packets as fast as you like, but if my end can’t process them that fast, either they’ll get dropped or you’ll knock me offline. Neither makes a valid scan.