LUKS Automatic unlock of with key file on remote ubuntu server

Question

Is there a way to automatically unlock a LUKS drive at boot time with the key-file being stored on a remote machine. The idea is to make sure servers may restart without any user input. Servers are on a public cloud and I can't encrypt the root partition. Leaving the key-file on the machine would simply defeat the purpose of encryption.

Hence the idea to have the key file in a remote machine connecting via a secure channel like ssh.

Mandos seems to do what I'm after but I've got two questions on it.
- All the documentation refers to the root file systems. Can it work with any drive?
- The documentation states that it only works on an intranet, would that work if the local and remote servers connects via a VPN?

Is it the best solution? the only solution?

Solution 1

tang and clevis can achieve that even with encrypted root partition on CentOS 7 (and I personally use it to automate boot on my home network and at work). Have a look and check if it plugs into your VM.

Solution 2

I have used Mandos to store and retrieve the passphrase to unlock the root file-system, to allow unattended reboots and simply store keys for all other volumes used by that system in a file on that encrypted root volume.

I have used mandos over a WAN connection (by configuring DHCP and the IP-address of the mandos server in the client system rather than relying on Zeroconf which only works in the local LAN) without bothering with a VPN connection.

Solution 3

You have various solutions online (like here) where a small ssh server (busybox+dropbear) is included in initrd to run it at boot time before filesystem mounting and let it be contacted to provide the passphrase as input.

You may be able to do something around that: in initrd, inside of launching a sshd server to wait for remote connection, start an ssh connection to your remote host storing keys, with specific ssh keys, in order to get the key file (doing an scp), then unlocking local filesystem with the LUKS key.

It is however not without drawbacks: you need of course to make sure to delete the downloaded LUKS key as soon as the unlock is done otherwise you gained nothing. Even better if you find a way to have it in RAM only for the time needed and not stored anywhere. Also, "any" attacker being able to read the content of your initrd may find the ssh connection and its ssh key, contact your remote host with them and download the LUKS key. If this happens it means however that your attacker is clearly targeting you and taking the time to study your specific setup, this is clearly outside of script kiddies. You should at least carefully review all connections that downloaded the key, the events should be tied to your other monitoring alerts showing that a given server is indeed rebooting (which again will not protect you against an attacker that was able to modify your initrd).

You also have to take into account cases where network fails at this moment, scp can not connect, etc... So having at the same time the option of the small sshdserver to be able to connect to it and debug things is not a bad idea. Or see what kind of out-of-band solutions your cloud provider can offer.

Comments

[user9517]

You may be able to use this with a monitoring solution github.com/dracut-crypt-ssh/dracut-crypt-ssh

[Michael Hampton]

If the servers are on a public cloud, it doesn't matter if you encrypt the storage or not, as the cloud provider will always be able to inspect your instance's RAM to find the encryption key.

[ludofet]

Thanks, You made me realise that the ssh keys have to be readable so "any" attacker with access to the HD would get them. If the remote server only answer request from the IP of the server I should reduce the risk of the keys being accessed from a rogue machine, right? I don't see how an attacker could get access to the initrd and not the unlocked partition (once the server has started) anyway. So I'm not sure I would be more at risk. I am missing something?

[Patrick Mevzek]

Yes you can force the source IP on the remote host for allowing ssh connections, but if you have an attacker already able to read your local ssh keys (that should be only readable by root) it probably means he can read all your (decrypted) disk anyway already. But you could tied the key provided to the source IP so that any machine could get only its decrypting key and no other (if you maintain more than one server with encrypted disks)