Encrypting a remote server disk
Answer
Full-disk encryption on a remote server uses LUKS2 with the passphrase entered at boot over an out-of-band console or a dropbear SSH shell in the initramfs. It protects against disk seizure and decommissioned-drive recovery. It does not protect a running server, whose keys are in RAM.
Be precise about the threat it addresses
Full-disk encryption protects data at rest. Once the machine is booted and the volume is unlocked, the key is in kernel memory and the filesystem is readable by anything with sufficient privilege — including, on a virtualised platform, a hypervisor operator who can dump guest RAM.
So FDE defeats: hardware seizure while powered off, drives leaving the datacentre at end of life, and a cold copy of your virtual disk image. It does not defeat: an attacker on the running system, or a hypervisor-level adversary against a running VM. Those are the honest boundaries and any guide that skips them is selling comfort.
The remote unlock problem
On a laptop you type the passphrase at boot. On a server two thousand kilometres away, something has to supply it, and the obvious solutions all defeat the purpose — a keyfile on the same disk, or a key stored by the provider, means the encryption is decorative.
There are two correct answers. On our dedicated and GPU servers, use the out-of-band console: IPMI gives you the boot screen and you type the passphrase like you would locally. On a VPS, put dropbear-initramfs in the initial ramdisk so the machine boots far enough to accept an SSH connection, you unlock over that connection, and boot continues.
Setting it up
The clean path is to encrypt at install time. Boot a custom ISO over virtual media, partition with an unencrypted /boot and a LUKS2 container for everything else, and install into it. Choose Argon2id as the key-derivation function — it is the LUKS2 default and it is memory-hard, which matters against brute force.
Order LUKS at provision on any dedicated, GPU or storage plan and we do the partitioning; you enter the passphrase over the console at first boot and it never touches our infrastructure. There is no charge and no recovery path, which is the same statement said twice.
- cryptsetup luksFormat --type luks2 --pbkdf argon2id /dev/sdaX
- Unencrypted /boot, everything else inside the container
- apt install dropbear-initramfs on a VPS for remote unlock
- Add your SSH key to /etc/dropbear/initramfs/authorized_keys
- Test a full reboot before you put anything on it
- Keep a second key slot with a passphrase stored somewhere safe
Two things people get wrong
The first is having only one key slot. LUKS2 supports eight; use at least two, with the second holding a long random passphrase kept in a password manager. A single forgotten passphrase is unrecoverable, and unrecoverable means unrecoverable.
The second is not testing a reboot before putting data on the machine. A misconfigured dropbear initramfs turns the first unplanned reboot into a machine that never comes back. Reboot it deliberately, twice, while it is still empty.
Frequently asked questions
01 Can my provider read an encrypted disk?
Not at rest. On a running VM, a hypervisor operator can in principle read guest memory, which holds the key — that is true of every virtualisation provider. Bare metal with LUKS removes that interface.
02 How do I unlock a server I cannot touch?
Out-of-band IPMI console on dedicated and GPU servers, or dropbear-initramfs on a VPS — the machine boots far enough to accept SSH, you unlock over it, and boot continues.
03 What if I forget the passphrase?
The data is gone. There is no recovery, no backdoor and no provider-held key. Use at least two LUKS key slots, with the second holding a long random passphrase in a password manager.
Related