NOTE: I need to update this with a more secure setup using the
command=. That way, one can’t accidentally get a shell.
One of the inconviences of encryption is the need to open the encrypted volume by hand when the computer/server boots. Luckily, you can easily automate that. You need a machine that will act as a key server.
Create a (passwordless/locked) user on the key server (and give the homedir 700 permissions). In its
~/.ssh/authorized_keys, give access to the public key of the root user of the machine with the encrypted volume, but only from one IP:
from="126.96.36.199" ssh-rsa yadiayadslkfjadwer root@host
Then on the machine that has the encrypted volume, put the following in something like
ssh -4 -o PasswordAuthentication=no email@example.com "cat luks.key" | cryptsetup --key-file - luksOpen /dev/raidvg/encryptedvolume decryptedvolume # put the proper entry in /etc/fstab so this mount works mount /mnt/decryptedvolume
The less obvious flags:
-4is to make sure the
fromclause will always work, also if your ISP suddenly gives you IPv6.
-o PasswordAuthentication=nois necessary to be sure the command fails if the login fails. Otherwise, should your IP address change, the command may hang on password input (if it’s not smart enough to detect a non-interactive terminal).
Lastly, you may want to remove the
-e from the shebang of
/etc/rc.local, so that the script continues when one command fails. I don’t understand why the
-e is there. There is no
/etc/rc.local.d/ or anything like that on Linux systems, so it will contain unrelated commands. It needs to continue when one fails.