Full disk encryption on a remote server has an obvious problem: something must supply the passphrase at boot, and there is nobody at the console.

A reboot leaves the machine sitting at a prompt nobody can see, requiring IPMI, a provider’s KVM console, or a trip to the rack.

Dropbear in the initramfs lets you SSH in and type it.

How it works

The initramfs is a small filesystem the kernel unpacks into RAM before mounting the real root. Its job is to load drivers, find the root device, and mount it, and with encryption that means unlocking it first.

Adding Dropbear, a very small SSH server, and a network configuration means the initramfs can bring up networking and accept a connection. You log in, type the passphrase, and the boot continues.

Debian and Ubuntu

sudo apt install dropbear-initramfs

# /etc/dropbear/initramfs/dropbear.conf
DROPBEAR_OPTIONS="-I 180 -j -k -p 2222 -s -c cryptroot-unlock"

Each flag matters:

-p 2222 uses a different port from the running system’s sshd, which avoids the host key conflict described below.

-s disables password authentication. Keys only.

-j -k disable port forwarding in both directions. This is an SSH server with no filesystem and one job; forwarding is an unnecessary capability.

-c cryptroot-unlock forces every session to run the unlock command. Even with a valid key you get the passphrase prompt and nothing else, not a shell.

-I 180 idles out after three minutes.

Authorised key

sudo mkdir -p /etc/dropbear/initramfs
ssh-keygen -t ed25519 -f ~/.ssh/unlock_key -C "luks unlock"
sudo cp ~/.ssh/unlock_key.pub /etc/dropbear/initramfs/authorized_keys
sudo chmod 600 /etc/dropbear/initramfs/authorized_keys

Use a dedicated key, not your normal one. This key is for one purpose and belongs nowhere else.

Networking

The initramfs needs an address before the network configuration on the root filesystem is available.

# /etc/initramfs-tools/initramfs.conf
IP=203.0.113.10::203.0.113.1:255.255.255.0:server01:eth0:off

The fields are client-ip::gateway:netmask:hostname:interface:autoconf. DHCP works with IP=dhcp and a static address is more reliable, because a DHCP server that is slow or absent leaves you with no way in at all.

The interface name is the one the kernel assigns at that stage, which may not match what you see once the system is up. Check it from the initramfs if you are unsure.

sudo update-initramfs -u -k all

Unlocking

ssh -p 2222 -i ~/.ssh/unlock_key root@203.0.113.10
# Please unlock disk nvme0n1p3_crypt:

Type it, the boot proceeds, and the connection closes as the machine pivots to the real root.

Arch

# with mkinitcpio and the systemd hooks
sudo pacman -S mkinitcpio-netconf mkinitcpio-dropbear mkinitcpio-utils

# /etc/mkinitcpio.conf
HOOKS=(base udev autodetect modconf kms keyboard keymap consolefont block netconf dropbear encryptssh filesystems fsck)

sudo cp ~/.ssh/unlock_key.pub /etc/dropbear/root_key
sudo mkinitcpio -P

The kernel command line carries the network configuration, which our kernel parameters guide covers:

ip=203.0.113.10::203.0.113.1:255.255.255.0::eth0:none

The host key warning

The first thing that will confuse you.

The initramfs Dropbear has its own host keys, different from the running system’s sshd. Same address, two different keys, and your SSH client will refuse to connect claiming a possible attack.

The clean fix is the separate port plus an explicit entry:

# ~/.ssh/config
Host server01-unlock
    HostName 203.0.113.10
    Port 2222
    User root
    IdentityFile ~/.ssh/unlock_key
    UserKnownHostsFile ~/.ssh/known_hosts.unlock
    HostKeyAlias server01-initramfs

ssh server01-unlock

HostKeyAlias stores the key under a distinct name, so the two never collide. Our SSH config builder covers the file.

The honest security position

The initramfs is unencrypted. It has to be, because it runs before anything is unlocked.

That means the Dropbear host keys sit on an unencrypted partition. Anyone with physical access can read them and impersonate your server’s unlock prompt, then capture your passphrase when you type it.

Mitigations, none of which fully solve it:

Dedicated keys, so a compromise is contained to this function.

-c cryptroot-unlock, so even a valid session cannot become a shell.

Secure Boot with your own keys and a unified kernel image, which puts the initramfs inside the signature and makes tampering with it detectable.

That last one is the real answer, and it is why the two topics belong together: remote unlock without a signed initramfs trusts something anyone with physical access can modify.

If your threat model is a stolen disk, this setup is fine. If it is a sophisticated attacker with physical access to the running machine, remote unlock is a weak point.

The alternative

sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/nvme0n1p3

A TPM-sealed key boots unattended with no passphrase at all, releasing the key only if the boot measurements are unchanged.

The tradeoff is straightforward: the disk unlocks for anyone who powers the machine on. If the threat is someone stealing the server, that defeats the purpose entirely, because they get a machine that boots.

TPM unlocking suits a machine in a physically controlled location where the threat is disk removal rather than theft of the whole system. Remote unlock suits a machine somewhere you do not control.

Keep a passphrase slot enrolled either way:

sudo cryptsetup luksDump /dev/nvme0n1p3 | grep -c "^  [0-9]: luks2"

More than one keyslot, always. A firmware update changes TPM measurements and a machine that will not unlock and has no fallback is a machine you have encrypted away from yourself.

Frequently Asked Questions

Why does an encrypted server need manual intervention to boot?

The root filesystem is encrypted, so the initramfs must obtain the passphrase before it can mount anything. With no console attached there is nobody to type it, which is why an encrypted remote server hangs at boot until someone intervenes.

How does SSH work before the root filesystem is mounted?

Dropbear is a very small SSH server embedded in the initramfs along with its own host keys and your authorised public key. It runs from the initramfs in RAM with a minimal network configuration, so you connect, supply the passphrase, and boot continues.

Is it safe to put an SSH server in the initramfs?

The initramfs is unencrypted, so the Dropbear host keys sit on an unencrypted partition where anyone with physical access can read them. Use keys dedicated to this purpose, never your normal host keys, and restrict the authorised key to only run the unlock command.

Why does my SSH client warn about a changed host key?

Because the initramfs Dropbear and the running system’s sshd present different host keys on the same address. The clean fix is a separate known_hosts entry, usually by connecting on a different port or using a HostKeyAlias in your SSH configuration.

What is the alternative to typing the passphrase remotely?

A TPM-sealed key, where the chip releases the passphrase automatically if the boot measurements are unchanged. That gives unattended boot at the cost that the disk unlocks for anyone who powers the machine on, which defeats the purpose if the threat is physical theft.

Does this work with a remote server at a hosting provider?

Yes, and it is the main reason to set it up. It requires the provider to give the machine a working network configuration in the initramfs, which usually means a static address, and that you can reach the port. Test it before you need it.