Encrypting disks remotely
Encryption on a server in someone else's rack is useful, but only if you have thought about who types the passphrase at four in the morning.
What it protects against
A disk that leaves the building: a failed drive going out for replacement, hardware being decommissioned, equipment physically removed. In those cases encryption is the difference between a non-event and a data breach.
What it does not protect against is anything happening while the machine is running. Once the volume is unlocked, an attacker with root reads it just like you do. Encryption is not a substitute for keeping the machine locked down.
The unlock problem
An encrypted root volume asks for a passphrase at every boot, and your machine is in a rack you cannot reach. Three workable answers:
- Type it over the console. Open remote KVM after a reboot and unlock it there. Simple, no extra moving parts, but it means you must be awake.
- Unlock over SSH at boot with dropbear in the initramfs. The machine comes up with a tiny SSH daemon, you connect and give the passphrase. Test this before you rely on it.
- Encrypt only the data volume and leave the root filesystem plain. The machine boots unattended, and you unlock the data after. For most people this is the sweet spot.
If you forget the passphrase
Then the data is gone. We cannot recover it: we have no key and no access, which is exactly the point of the arrangement. Keep the passphrase somewhere other than on the server, and make sure a second person in your company can reach it.
What we do on our side
Disks that pass back through our hands are wiped before they are reused, and a dead disk that cannot be wiped is destroyed. Encryption is for the case where that is not enough for you — and it does not replace backups, which should be encrypted too.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base