LUKS keyscript being ignored ... asks for password

Question

Let me begin by saying I'm not new to LUKS. I've set up LUKS with keyscripts numerous times with and without LVM. I'm not sure what is actually going on here though. I have a system that has a single encrypted partition. My drive is organized as follows:

# lsblk

NAME             MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda                8:0    0  128G  0 disk  
└─sda1             8:1    0  128G  0 part  
  ├─vg0-root     253:1    0   20G  0 lvm   /
  ├─vg0-secure   253:6    0  100M  0 lvm   
  │ └─secure     253:7    0   98M  0 crypt /root/secure
  └─vg0-swap     253:4    0    1G  0 lvm   [SWAP]

My /etc/crypttab file looks something like this

# UUID is not required here since the path to the LV won't change
secure      /dev/vg0/secure       none      luks,keyscript=/lib/cryptsetup/scripts/insecure

My /lib/cryptsetup/scripts/insecure file is executable and looks something like this

#!/bin/sh
# My actual file looks somewhat different because it dumps the key file with dd.
# This accomplishes virtually the same thing though.

echo -n "my-encryption-password"

I have run update-initramfs -k all -u a number of times after configuring crypttab and putting my keyscript file in place.

As far as I can tell, my script file isn't even getting copied to the initrd.img file. Now that I think about it, I don't think it would get copied to the initrd.img file since the root partition is not encrypted and the script file should be easily accessible from there.

Upon rebooting, the system sees the record from crypttab and asks for a password (which in my case doesn't actually exist because the only key is a keyfile full of random bits) rather than using the keyscript to unlock the LUKS partition. I have tried taking LUKS out of the LVM and putting it on sda2, and the results were the same. I also know that the keyscript works because cryptsetup luksOpen /dev/vg0/secure secure -d - <<< "$(/lib/cryptsetup/scripts/insecure)" works like a charm and decrypts my LUKS partition.

I've tried this in Ubuntu 16.04.2 and Ubuntu Mate 16.04.2 with the same results. I've used keyscripts before without any trouble. The only difference was that, in the past, my / partition was always encrypted. If anyone can shed some light, I'd appreciate it. I only want a very small encrypted partition because I plan on cloning this system, and I don't want to clone it with the entire / partition encrypted.

---

UPDATE 2017-04-26

In digging through logs, I found a line with the following error which makes no sense. Since when is 'keyscript=/path/to/script' an unknown option for crypttab?

... systemd-cryptsetup[737]: Encountered unknown /etc/crypttab option 'keyscript=/lib/cryptsetup/scripts/insecure', ignoring.

Just for kicks, I tried removing the keyscript option and using a keyfile, and it all just worked! In fact, I tried other options like keyfile-offset, and they work too. Hence, the problem lies somewhere with the keyscript option. Does anyone have any idea why?

Solution

Try the option "initramfs" in your /etc/crypttab (according to https://unix.stackexchange.com/a/447676/356711). Your /etc/crypttab would then look like this:

# UUID is not required here since the path to the LV won't change
secure      /dev/vg0/secure       none      luks,keyscript=/lib/cryptsetup/scripts/insecure,initramfs

Please note that it might be a problem that your root fs is in an LVM container. This issue is also mentioned in the article linked above: "But this currently only works (reliably) if the root device is not in an LVM." Fortunately, it seems that a workaround is provided.

My system looks like this:

$ lsblk
NAME                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                             8:0    0 931.5G  0 disk
└─sda1                          8:1    0 931.5G  0 part
  └─md1                         9:1    0 931.4G  0 raid1
    └─md1_crypt               253:3    0 931.4G  0 crypt
      └─raid_crypt_vg-data_lv 253:4    0 931.4G  0 lvm   /raid
sdb                             8:16   0 931.5G  0 disk
└─sdb1                          8:17   0 931.5G  0 part
  └─md1                         9:1    0 931.4G  0 raid1
    └─md1_crypt               253:3    0 931.4G  0 crypt
      └─raid_crypt_vg-data_lv 253:4    0 931.4G  0 lvm   /raid
sdc                             8:32   0 465.8G  0 disk
├─sdc1                          8:33   0   953M  0 part  /boot
└─sdc2                          8:34   0 464.8G  0 part
  └─sdc2_crypt                253:0    0 464.8G  0 crypt
    ├─system_crypt_vg-data_lv 253:1    0   447G  0 lvm   /
    └─system_crypt_vg-swap_lv 253:2    0  17.8G  0 lvm   [SWAP]

... and the following /etc/crypttab does the decryption magic with a keyscript (!) in Ubuntu 18.04.2 LTS:

$ cat /etc/crypttab
# <target name> <source device>                           <key file> <options>
sdc2_crypt      UUID=[...]                                none       luks,discard,keyscript=/etc/decryptkeydevice/decryptkeydevice_keyscript.sh
md1_crypt       /dev/md1                                  none       luks,discard,keyscript=/etc/decryptkeydevice/decryptkeydevice_keyscript.sh,initramfs

Note that the decryption of sdc2_crypt with the provided keyscript works without the initramfs option (because it contains the root fs and is thus "automatically" considered in the initramfs boot phase). md1_crypt was only decrypted already during the initramfs boot phase (and thus with the keyscript according to the crypttab entry) after I added the initramfs option. The later decryption of md1_crypt during the systemd boot phase does not work with a keyscript given in crypttab because the "systemd cryptsetup" does not support the option keyscript, see https://github.com/systemd/systemd/pull/3007.

Comments

[sergtech]

I think systemd is your problem. A quick google for systemd and keyscript shows a bug and a pull request for implementing keyscript in systemd here. There's even a workaround available from the first link.

[b_laoshi]

This has been my suspicion as well as I have continued digging into my issue and searching results I've found online. I tried some recommendations here, but I'm not sure how to get the script file into the initrd.

[b_laoshi]

That doesn't actually address the issue of using a custom keyscript. The correct answer is to use the initramfs option in the crypttab entry so that the custom script gets bundled into the initramfs. What you suggest does not allow using a tool like dd to dump the key directly from a specific device. Neither does it allow for any other potentially scripted manipulations to obtain the appropriate key.