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.

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.

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.

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.

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

use ddns or similar to keep track of tour IP?

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.