/etc/crypttab, Systemd and keyscripts

I’ve upgraded some of my systems to Ubuntu 15.04 and found that some system didn’t boot due to poorly documented interactions between Systemd and /etc/crypttab.

The major bug is around keyscripts, Debian and Ubuntu have for a long time supported using a binary or script to provide a password for encrypted devices, from the Debian crypttab man page:

keyscript= The executable at the indicated path is executed with the key file from the third field of the crypttab as its only argument and the output is used as the key.

People have used this for all sorts of creative ways of getting passwords from TPM chips, cryptocards etc.

The root of the problem is that systemd doesn’t support keyscripts at all, and in fact doesn’t even parse /etc/crypttab on boot.

I have worked round this bug by moving all my keyscript dependant volumes to start post system boot. The command cryptdisks_start still uses /etc/crypttab and keyscripts correctly, so I have added either nofail or noauto options to the devices in /etc/fstab and /etc/crypttab to allow the system to boot.

Another minor bug I encountered was caused by using the system UUID as a simple password for my backup disk. While this isn’t the worlds most secure key it is unique to my laptop and accessible to the system without any user interaction.

I did this by setting keyfile in /etc/crypttab to /sys/class/dmi/id/product_uuid. The bug is that systemd interprets the /sys path and for reasons I’ve not looked at in depth doesn’t start the LUKS device. The simple fix is to change the keyfile path and symlink the /sys file to the new location ie:

 sudo ln -s /sys/class/dmi/id/product_uuid /boot/uuid



2 thoughts on “/etc/crypttab, Systemd and keyscripts”

  1. I’ve been using my luks encrypted disks with custom keyscripts since Ubuntu 10.10 and now systemd screwed everything up. Don’t know who to blame, Ubuntu maintainers or Systemd devs, and I’d like to know that because if it is Ubuntu’s fault I would rather switch to Fedora. Hopefully we can still boot with upstart.

    1. The key script is a Debianisum that Ubuntu has adopted so moving to Fedora won’t help. I’d argue this is a mixture of Ubuntu and Systemd, poor communication from Ubuntu and breaking of existing functionality in the name of progress from Systemd.

      On to some short term fixes, I’ve moved all my key script dependant LUKS volumes to be a post boot thing. What isn’t well documented is that /etc/crypttab is not used at boot, instead there are systemd units built from it. This means that you can use cryptdisks_start with key scripts fully supported and then mount /path.

      If you set the noauto or nofail options in /etc/crypttab and /etc/fstab at least the system will boot and you can then use cryptdisks_start. However this won’t work if / is on a key script dependant volume.

Comments are closed.