Mdthbs

I'm trying to decrypt the Debian root with a key file stored in the boot partition (decrypted partition). This will break the security, but it doesn't matter now. I have to conclude this successfully or die trying.

I have created the hooks to the initramfs and the key file is on the /boot directory inside the initrd.img-* file. The path to the key file (/boot/keyfile) is on the /etc/crypttab file.

I updated the initramfs with sudo update-initramfs -u but I received this message: cryptsetup: WARNING: target sdaX_crypt uses a key file, skipped.

Ignoring the message and rebooting results in a unbootable disk. The message Gave up waiting for root device. is displayed and drops to initramfs shell.

In the initramfs environment the cryptsetup don't exists. (It should exists?)

Seens that the update-initramfs -u "thinks" the sdaX_crypt device will be mounted in another way and don't configure to decrypt with the keyfile.

How can I do that?

You can use the keyscript option in your crypttab instead (man crypttab). Just create a script that echos your passphrase and set it as the keyscript argument, then regenerate your ramfs. You don't need any hooks, and you don't need to put the script in /boot/.

vg1-root_crypt UUID=94a3b301-123-12-a3-ea0403 none luks,keyscript=/etc/echo-root-luks-pass


I don't know why the initramfs hooks for cryptsetup prohibit you from just having the keyfile listed in crypttab. Probably don't want to condone such behavior.

P.S. I don't think that it breaks the security, it just weakens it more or less depending on how secure your /boot partition is. You could for example /boot off a USB drive, and keep the USB in you socks etc.

To really ignore the message and do not skip the partition, you need (at least) comment out/delete the return 1 in /usr/share/initramfs-tools/hooks/cryptroot after the line where the error message
is written (around line 274 - depening on the used cryptsetup version). Beware that this file is by default managed by the package manager,
and therefore is overwritten at any update of the cryptsetup package.

Please read also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776409
for more information about the issue.

I have not tested it, there could be other reasons than the mentioned why the case of a keyfile is
not considered.

If my memory serves me well, your problem is that your fstab is modified to point to the encrypted partition, since you have booted from an unencrypted partition your fstab (while you are executing update-initrd) should point to your unencrypted volume. AFTER you have created the initrd image you can modify your fstab to point to the encrypted partition.

Keyfiles matching the shell-style (globbing) pattern KEYFILE_PATTERN defined in /etc/cryptsetup-initramfs/conf-hook will be included in the initramfs, but the other keyfiles will not, according to Debian's cryptsetup docs:

• For Debian 9: /usr/share/doc/cryptsetup/README.{initramfs,Debian}.gz
  


• For Debian 10: /usr/share/doc/cryptsetup{-initramfs/README.initramfs,-run/README.Debian}.gz.

I am not sure about previous versions of Debian.

These files are readable with zless filename.gz, but here it is the relevant part, for convenience and future reference.

12. Storing keyfiles directly in the initrd

Normally devices using a keyfile are ignored (with a loud warning), and the key file itself is
not included in the initrd, because the initramfs image typically
lives on an unencrypted /boot partition. However in some cases it is
desirable to include the key file in the initrd; for instance recent
versions of GRUB support booting from encrypted block devices,
allowing an encrypted /boot partition.

Among the key files listed in the crypttab(5), those matching the
value of the environment variable KEYFILE_PATTERN (interpreted as a
shell pattern) will be included in the initramfs image. For instance
if /etc/crypttab lists two key files /etc/keys/{root,swap}.key, you
can add the following to /etc/cryptsetup-initramfs/conf-hook to add
them to the initrd.

KEYFILE_PATTERN="/etc/keys/*.key"

Furthermore if the initramfs image is to include private key material,
you'll want to create it with a restrictive umask in order to keep
non-privileged users at bay. This can be achieved by adding the
following to /etc/initramfs-tools/initramfs.conf.

UMASK=0077