Unlock LUKS Remotely on Ubuntu 16.04 LTS

I reinstalled my little server at work. It had been running the same Gentoo setup since 2008 (!) but in December 2017 the Gentoo folks finally managed to produce a convoluted enough update to completely hose the darn thing. Well, not "hose" as in "disaster" of course: I got all the data off safely and I could even leave it running over the holidays while I was away in Germany. But in preparation for the Spring 2018 semester it was necessary to "start from scratch" as it were.

Upset enough with Gentoo I decided to go completely the other way and do a minimal Ubuntu 16.04 LTS install. I also used this opportunity to finally add full-disk LUKS encryption to my setup. Not that it makes much sense (the server runs 24/7 so it's basically always decrypted) but what the heck, this is how you're supposed to set up your server, right? And instead of going for ZFS or btrfs (which is what I used on my new home machine), I went "retro" one last time:

1. Partition the disks into one "small" boot partition and one "large" data partition.
2. Use mdadm to create a RAID-1 boot and a RAID-10 data array.
3. Use cryptsetup to LUKS-encrypt the "huge" data RAID array.
4. Use LVM to create swap, root, and various home volumes in the encrypted RAID.

Great! But now I had a problem. You see, every now and then we actually have a power outage. (I know it's weird, but since we're not the hospital we apparently don't get to have a redundant power grid.) I might not be around to reboot the machine manually, but students want to submit their homework assignments. And I don't like giving extensions. So what to do?

Enter the recent dropbear-initramfs package! This thing is supposed to integrate a tiny dropbear SSH server into the early root filesystem, enabling "remote unlocking" of the encrypted RAID array. And it almost works. First the easy parts:

1. apt install dropbear-initramfs (and ignore the error message)
2. mkdir -p /etc/initramfs-tools/root/.ssh/
3. Put your SSH keys into /etc/initramfs-tools/root/.ssh/authorized_keys
4. update-initramfs -u

Now when the machine boots up, it'll still ask for a passphrase on the console, but it will also start the dropbear SSH server. In theory you can ssh in as root at that point and run the unlock script, but that didn't work for me. What did work, however, is to echo the passphrase directly to the FIFO created by cryptsetup:

1. ssh root@server
2. echo -n passphrase >/lib/cryptsetup/passfifo
3. exit

At this point the encrypted RAID will come up and the boot process will continue, just as if you had typed the passphrase at the console. I am positive that they'll eventually fix the scripts, but for now I am just happy that I was able to make it work.

Note that it's convenient to run dropbear SSH and the regular OpenSSH on different ports to avoid getting loads of useless warnings when connecting. It's also just good sane practice if you want to keep the number of script kiddies trying to get into your server down to a minimum. Yes, security through obscurity is bad, but it's only really bad if it's your only approach. Happy remote booting!