You are not logged in.
I have an encrypted root partition setup with LUKS that I unlock via a passphrase typed in at boot. I'm using the systemd-encrypt hooks. The boot partition (EFI system partition) is on the same physical drive and is not encrypted.
I understand how to add a second key to the encrypted root partition via the luksAddKey command and I also understand how to specify a keyfile in place of the passphrase by changing the kernel options called in the bootloader (and loading the relevant modules in the mkinitcpio file in this case). But what I can't figure out is how I can change the setup to look for a keyfile at boot and then if that is not found, ask for a passphrase. For example, to unlock via a keyfile on a usb drive at boot OR if that is not found/plugged in, to instead ask for the passphrase. Is that possible for an encrypted root partition? I am well aware this idea lowers, rather than improves, the security of the system - but that is acceptable to my use case. I read through the details of crypttab and it specifies in the wiki that is read after boot so not suitable for unlocking a root partition. From what I've read (and tested so far) it seems that via the bootloader and kernel options specified I can only unlock multiple drives with one passphrase (i.e. where they have the same passphrase) but I haven't figured out how to do what I describe above, i.e. look first for a keyfile and then if that is not found ask for a passphrase.
(edit) corrected typo in post title
Last edited by rxl_980 (2019-03-20 21:49:30)
Offline
AFAIK you don't need any special configuration for that. If the keyfile is not available, it should fall back to asking for a passphrase.
Looks like it doesn't work like that. If the device with the keyfile is removed, systemd times out waiting for it and you get dumped to emergency mode.
Last edited by nl6720 (2019-03-21 10:11:51)
Offline
Hi nl6720. That was my experience too. Thank you for trying it out, at least good to hear someone else has the same result as me.
My current thinking is that it might be possible to edit the initramfs to allow a shell script to be run which queries for a USB drive at a specific location and then fails over to the default passphrase request if it is not found after a few tries. Just trying to work out how to implement that to test it currently. I am going to try in a VM as I'm certain I will break something in the process as that's way beyond my current level of knowledge.
Offline
I would suggest opening a issue in https://github.com/systemd/systemd/issues, asking for this functionality.
Offline
But what I can't figure out is how I can change the setup to look for a keyfile at boot and then if that is not found, ask for a passphrase.
That is exactly how the encrypt hook works and how I am using it for several years now.
Background:
I administer several servers that are fully encrypted using LUKS.
To be able to reboot them remotely, I introduced the following scripts and systemd units:
/usr/local/bin/reboot
#! /bin/bash
/usr/bin/cryptsetup luksAddKey /dev/disk/by-uuid/240b50c1-5893-4b01-88af-10d7971d6204 /boot/keyfile && /usr/bin/systemctl reboot
/etc/systemd/system/clear-luks-key.service
[Unit]
Description=Remove auto-unlock LUKS key
[Service]
Type=oneshot
ExecStart=-/usr/bin/cryptsetup luksRemoveKey /dev/disk/by-uuid/240b50c1-5893-4b01-88af-10d7971d6204 /boot/keyfile
[Install]
WantedBy=multi-user.target
The LUKS keyfile is obviously stored on the not-encrypted /boot partition:
$ LANG=C ls -la /boot/keyfile
-rwxr-xr-x 1 root root 256 Mar 19 23:57 /boot/keyfile
And the bootloader provides the respective arguments:
linux /vmlinuz-linux root=UUID=b62d6afc-d625-4796-bd27-b1f830b24f9b rw cryptkey=/dev/disk/by-label/boot:auto:/keyfile init=/usr/lib/systemd/systemd cryptdevice=UUID=240b50c1-5893-4b01-88af-10d7971d6204:root quiet
tl;dr
Use the encrypt hook instead.
Last edited by schard (2019-03-21 12:39:19)
Inofficial first vice president of the Rust Evangelism Strike Force
Offline
I just found a feature request for this: https://github.com/systemd/systemd/issues/12194. Doesn't look like anyone's working on it though.
Offline