Imagine you have a Linux server, and you want to use full-volume encryption (in this case meaning your root partition being encrypted).
Of course, by default, this means you have a prompt at boot to unlock. That’s not really practical for a server.
One could, of course, put the key into the initramfs for auto-unlocking. But this only makes sense with old-school HDDs where you can safely wipe the boot partition before decommissioning the drive, and it does not protect from attacks where one obtains the HDD before proper decommissioning.
There are also TPMs, but those are not that well supported in the Linux world.
But, there’s one more option! Remotely unlocking the server through SSH!
Overview
For this to work, you need a plaintext (meaning unencrypted) /boot partition.
What we’ll do, is put Dropbear (an SSH server) into the initramfs (that’s the thing that first boots in Linux).
We’ll also add the authorized SSH keys to that Dropbear server, such that we can authenticate.
Then, during boot, Dropbear will launch and wait for connections.
You connect through SSH, and run the command cryptroot-unlock, enter the encryption password and unlock the drive.
It will then continue to boot as usual after unlocking.
Prerequisites
In this guide, I’m assuming the OS is Ubuntu Server 22.04, so you might have to adapt it to your distro, but the concept is the same.
This also assumes an installation using DHCP.
Installing Dropbear
First, we’ll install Dropbear for the initramfs, and dhclient (needed to get an IP at boot):
apt install dropbear-initramfs isc-dhcp-client
touch /etc/dropbear/initramfs/authorized_keys
chmod 0600 /etc/dropbear/initramfs/authorized_keys
Now edit /etc/dropbear/initramfs/authorized_keys
and add your SSH public key into it.
You can optionally config Dropbear in /etc/dropbear/initramfs/dropbear.conf
What if I’m not using DHCP?
Then you can edit /etc/initramfs-tools/initramfs.conf
And add the line
IP=192.168.1.2::192.168.1.1:255.255.255.0:ubuntu
Where you have to adjust the IP addresses, in the following order: Host IP, Gateway IP, Netmask. The last point is the hostname.
Finally, update the ramdisk
update-initramfs -u -k all
This will update all the ramdisks (initramfs).
In theory, you could reboot now, connect through SSH and run cryptroot-unlock
, then enter your encryption key and continue the boot process.
But note: In the case of DHCP, the IP used in Dropbear might differ from the IP for the booted installation. If you’re lucky, the IP will be the same.
Fix SSH client
Your SSH client might complain because the host key is different for the Dropbear install.
Edit ~/.ssh/config
and add the line UpdateHostKeys no
Then, comment out the host in question in ~/.ssh/known_hosts
after rebooting to Dropbear, connect, accept the fingerprint, then remove the comment again. Now you should have both keys accepted in your SSH client.
Final Notes
This is just an outline, and worked well for me using Ubuntu 22.04, but I can’t guarantee it will work just as well for you. So, follow this guide at your own risk!
Note that I run this blog in my free time, I hope I helped you out, and donating a coffee would be greatly appreciated!
Update 2024-01-09
I recommend editing /etc/dropbear/initramfs/dropbear.conf
and uncommenting:
IFDOWN="*"
This will make sure that network interfaces are brought down cleanly before exiting the ramdisk.
I also recommend setting some options:
DROPBEAR_OPTIONS="-p 22 -j -k -s -c cryptroot-unlock"
This will set the SSH port to 22, disable local and remote port forwarding, disable password authentication and also make sure that cryptroot-unlock will be the only command you can execute when logging in. Make sure to rebuild your initramfs as shown above if you change these options.
[…] 🚨 If you really want to protect your server data, even from entire physical takeovers and not just HDD decommissions, you want to follow my other guide that requires manual unlocking over SSH. […]
[…] If you get troubled with SSH key fingerprints (because the boot process and the actual OS have differing fingerprints), check out my other guide, specifically the “Fix SSH clients” section. […]
@sindastra Looks good 👌
I wonder if a response will also go out to fedi…