Ubuntu – LUKS keyscript being ignored … asks for password

16.04bootencryptionluks

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?

Best Answer

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.

--before starting make sure you have a backup and can also boot your system with ubuntu cd or usb; as if you make a mistake, your system may not boot anymore or you may loss data. i assume you have an encrypted ubuntu system with LUKS, inside LUKS you have 3 partitions, SYSTEM-BOOT (not encrypted), SYSTEM-SWAP (encrypted) and SYSTEM-OS (encrypted)--

u need to adjust UUIDs, SYSTEM-SWAP_crypt, SYSTEM-OS_crypt, SYSTEM-SWAP, SYSTEM-OS to the variation used on your system, pls see reference link below my solution for more info

Get UUIDs:

blkid

Prepare >

swapoff /dev/mapper/SYSTEM-SWAP_crypt
cryptsetup luksClose SYSTEM-SWAP_crypt

Tell cryptsetup to compute the passphrase of the swap partition from the decryption key of the volume holding the root filesystem >

/lib/cryptsetup/scripts/decrypt_derived SYSTEM-OS_crypt | cryptsetup luksFormat /dev/mapper/SYSTEM-SWAP --key-file -
/lib/cryptsetup/scripts/decrypt_derived SYSTEM-OS_crypt | cryptsetup luksOpen /dev/mapper/SYSTEM-SWAP SYSTEM-SWAP_crypt --key-file -
mkswap /dev/mapper/SYSTEM-SWAP_crypt

tell the system about swap partition, edit crypttab>

nano /etc/crypttab

=? make sure two lines match

SYSTEM-OS_crypt UUID=uuid-of-luks-containing-osroot none luks
SYSTEM-SWAP_crypt UUID=uuid-of-luks-containing-swap SYSTEM-OS_crypt luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived

tell the system about swap partition, edit fstab>

nano /etc/fstab

=? make sure u have this line

/dev/mapper/SYSTEM-SWAP_crypt swap swap sw 0 0

tell the system about swap partition, edit resume>

nano /etc/initramfs-tools/conf.d/resume

=? make sure u have this line

RESUME=UUID=uuid-of-encrypted-swap-SYSTEM-SWAP_crypt

update initramfs on boot partition >

update-initramfs -u -k all

Reference

The answer inspired by Setting up an encrypted Debian system (archived link):

If you are using an encrypted Debian system, you likely have some security requirements to meet. If that's the case, you must also use an encrypted swap partition.

The swap partition can be encrypted in two ways:

it can be recreated on every boot, using a random passphrase, or

it can be created like the other encrypted volumes with a persistent passphrase

If you want to use suspend-to-disk, you cannot use the first approach as it would overwrite your memory footprint stored in the swap partition. Furthermore, you cannot use a key file like the other partitions, since the root filesystem is not (and must not) be mounted by the time the resume process starts and needs to read the decrypted swap partition.

The way I solved this is by telling cryptsetup to compute the passphrase of the swap partition from the decryption key of the volume holding the root filesystem; the cryptsetup package implements this with /lib/cryptsetup/scripts/decrypt_derived. Thus, to set up the swap partition, I do the following, assuming hda2 is the partition holding the encrypted swap and the root filesystem is in hda5_crypt:

swapoff /dev/mapper/hda2_crypt
cryptsetup luksClose hda2_crypt
dd if=/dev/urandom of=/dev/hda2
/lib/cryptsetup/scripts/decrypt_derived hda5_crypt \
  | cryptsetup luksFormat /dev/hda2 --key-file -
/lib/cryptsetup/scripts/decrypt_derived hda5_crypt \
  | cryptsetup luksOpen /dev/hda2 hda2_crypt --key-file -
mkswap /dev/mapper/hda2_crypt

To tell the system about this swap partition, we need to add it to /etc/crypttab and /etc/fstab; make sure, those files contain lines like the following:

/etc/crypttab:
  hda2_crypt /dev/hda2 hda5_crypt luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived

/etc/fstab:
  /dev/mapper/hda2_crypt swap swap sw 0 0

With this in place, as soon as you configure the system for suspend-to-disk, the swap partition will be automatically set up alongside the root filesystem very early during the boot sequence. To figure out which swap partition to make available at that point, cryptsetup checks the following: asfasfafs - a line like RESUME=/dev/mapper/hda2_crypt in /etc/initramfs-tools/conf.d/resume - a resume device setting in /etc/uswsusp.conf (see uswsusp.conf(5)) - an entry in /etc/suspend.conf - a resume=/dev/mapper/hda2_crypt in the kernel command line

You can inspect /usr/share/initramfs-tools/hooks/cryptroot if you want to know more about this.

Ubuntu – Full System encryption with LUKS on headless server – unlock with dropbear and busybox. How

This is more a comment than an answer, sorry. But since you didn't get any replies yet, I wanted to write something anyway.

As for how does it even work:

In the Initramfs you usually have one master process (usually a busybox based /init shell script) which is responsible for making the root partition available before handing off the boot process to the real init system of your Ubuntu install.

In case of dropbear in Initramfs, that is a separate process started by /init. Logging into dropbear you get a shell which is yet another process. All the while the original /init has to be running and waiting for something, in this case the LUKS password.

So what the /init script most likely does here, once it started dropbear, is create a named pipe, or fifo, i.e. the /lib/cryptsetup/passfifo. And then it reads from that named pipe. This read will block until there actually is something to read, so that's how /init hangs and waits for input.

Then some years later you log into dropbear and do your echo passphrase > /lib/cryptsetup/passfifo, at which point /init wakes up from its slumber and resumes to unlock LUKS and go on with the rest of the boot process.

And that's basically the general idea of how it works. If there is no documentation for it you would have to read the shell script.

As for a GPG encrypted key in Initramfs, I'm sure this is the standard method in Ubuntu somehow, probably to be set up via /etc/crypttab. Did you check the wiki for a howto?

It certainly would require GPG to be included in the Initramfs. but I outlined an alternative approach here which could be made to work without additional dependencies:

How do I use dm-crypt (LUKS) with GnuPG to use two-factor for FDE?

The problem with this is of course that it is not standard, so while it could be simpler in theory it might actually be harder to set up.

Best Answer

Related Solutions

Ubuntu – stop crypttab asking for password for swap

Reference

Ubuntu – Full System encryption with LUKS on headless server – unlock with dropbear and busybox. How

Related Question