Decrypt LUKS devices remotely via Dropbear SSH
Sometimes, when you’re not at the office, and your PC’s sitting there all properly shut down to save on electricity and it sure would be nice if you could just ask a co-worker to boot up the computer. Then you could use that wonderful technology known as SSH. Unfortunately, the encrypted hard drive makes this scenario impossible. In order to disable the encryption, someone has to type in the passphrase.
Now there’s a solution – the lightweight SSH server Dropbear, which you install in the initramfs. In addition, you ensure that the network interface is started and provide the encrypted partition.
On my Arch Linux, I had to take the following steps:
Install and configure Dropbear
First, you have to install the packages mkinitcpio-utils and mkinitcpio-dropbear from the AUR:
$ yaourt -S mkinitcpio-dropbear mkinitcpio-utils
These packages install the hooks required for the initramfs. Attached is a link to an example of how this sort of hook can be configured in Ubuntu.
After that, the public key which you’ll later use to log on to the system has to be saved in the file /etc/dropbear/root_key
. The file is structured like the known authorized_key files under ~/.ssh/
, so more than one key can be configured. But for each new key, you have to generate the initfamfs again!
Prepare mkinitcpio.conf
Next, adjust the /etc/mkinitcpio.conf
. For one thing, the kernel module for the network chip has to be added under MODULES=""
. You can use lspci
to find the module:
$ lspci -k
Under the devices, you’ll find the module loaded for them in the Kernel modules
line. For another, you need to add netconf
, dropbear
und encryptssh
before filesystems
in the hooks.
The whole thing should then look approximately like this:
[..]
MODULES="r8169"
HOOKS="base udev autodetect modconf block netconf dropbear encryptssh filesystems keyboard fsck"
After that, the initramfs has to be rebuilt:
$ mkinitcpio -p linux
Configure bootloader
In the bootloader, you’ll also need to add the options for the kernel line to the Linux kernel. In my case (systemd-boot) this can be found under /boot/loader/entries/arch.conf
. With GRUB, this can be done using variables in the file /etc/default/grub
(see Arch Linux Wiki).
One option is cryptdevice
, which indicates which device (that is, which partition) actually needs to be decrypted. The best thing to do here is to put in the UUID (ls -l /dev/disk/by-uuid/
), formatted as UUID=<effective-uuid>
and not the blockdevice name under /dev, because it can change.
The other option tells the kernel how the network should be configured. This option is simply called ip
and can either be configured by DHCP or manually. To use DHCP, just put in ip=:::::eth0:dhcp
. But in my case, I wanted a static configuration, so that I know where I have to connect to via SSH. The format is as follows: ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>:<dns0-ip>:<dns1-ip>
(also refer to the Kernel documentation), althouth this didn’t entirely apply to my case. I had to leave out the last colon for it to work. Also note that, for <device>
, you have to use the Kernel name (ethX) and not the Udev name:
dmesg | grep eno1
16.593465] r8169 0000:03:00.0 eno1: renamed from ==eth0==
The result looks like this:
title Arch Linux
linux /vmlinuz-linux
initrd /initramfs-linux.img
options ip=10.9.4.70::10.9.1.1:255.255.0.0:huckfinn:eth0:none: cryptdevice=UUID=9c53e8b6-07bf-4e9d-bb3e-feaf55c02f41 root=/dev/sda2 rw
Crypttab
I had previously provided my encrypted partition for decryption in /etc/crypttab
in the boot process. Since the partition is already defined by the parameter cryptdevice
, no more crypttab configuration is necessary. So the entry has to be removed there, because the partition is already open. In the fstab, it’s also no longer possible to use /dev/mapper/XYZ; but if you use the UUID, it works with no problem.
Now, it’s time to arm yourself with a live-boot USB stick and restart the computer. Ideally, it should look something like this:
If you’ve made a mistake in the IP configuration, it’s not so bad: The error message should be pretty straightforward. You can just keep booting and fix whatever needs adjustment. If, on the other hand, the cryptdevice parameter is wrong, you’re going to get stuck. Then you’ll need to boot the live system, mount the partition on which the configuration is located and correct the parameter.