On 2/26/2020 3:54 PM, Guilhem Moulin wrote: > Hi there, > > On Wed, 26 Feb 2020 at 07:37:33 +0100, john doe wrote: >> But here, I need to reenter the password for a second time. >> […] >> I'm just starting here, so any input is welcome. > > Let me try to rephrase what I wrote already in private. The document > you linked to (which I wrote and which is included to src:cryptsetup) > does say that you devices holding / and /boot need to be unlocked again: > > “The device holding the kernel (and the initramfs image) is unlocked > by GRUB, but the root device needs to be unlocked again at initramfs > stage, regardless whether it’s the same device or not. This is > because GRUB boots with the given vmlinuz and initramfs images, but > there is currently no way to securely pass cryptographic material > (or Device Mapper information) to the kernel. Hence the Device > Mapper table is initially empty at initramfs stage; in other words, > all devices are locked, and the root device needs to be unlocked > again.” > > So passed GRUB, all devices are locked. The one(s) holding the root > file system, /usr (and swap if suspend-to-disk is enabled) needs to be > unlocked at initramfs stage, while other crypttab(5) entries are > processed later by the “normal” system. This is why systemd asks you to > unlock the device holding /boot here: > >> "/dev/mapper/debian--bustervm--vg-root: recovering journal >> /dev/mapper/debian--bustervm--vg-root: clean, 31578/507904 files, 287395s >> Please enter passphrase for disk QEMU_HARDDISK (sda1_crypt):" > > There are 3 distinct stages: > > 1. At GRUB stage, you unlock the (LUKS1) device holding the kernel (and > the initramfs image), i.e., /boot. > > 2. At initramfs stage, the system has access to the content initramfs > image (which itself lives in the encrypted /boot), but the Device > Mapper table is initially empty so device(s) holding the rootfs and > /usr need to be unlocked and mounted before execution can be turned > over to the “real” init(1) binary. > One can unlock via key files to avoid the interactive passphrase > prompt(s). These keys files however need to be copied to the > initramfs image as its content is the only thing available at > initramfs stage. (Unless you want to use an external token and/or > activate the network stack.) > > 3. At “normal” stage, the system will take care of unlocking remaining > crypttab(5) entries, i.e., for devices that weren't required to be > unlocked at stage #2 (for instance for devices holding /boot, /var, > /sys, etc.). > Again, one can unlock via key files to avoid the interactive > passphrase prompt(s). At that point the rootfs is mounted, so > keyfiles can be dropped there, and don't need to be copied anywhere > else. > > Only device(s) unlocked at stage #1 need to comply with GRUB's > limitations: LUKS1 only (although there is an upstream patch for LUKS2 > now), limited RAM, limited cipher selection, etc. On the other hand > device(s) unlocked at stage #2 and #3 are processed by libcryptsetup, so > one can use any feature available there, including LUKS2 on-disk format, > use of kernel keyring tokens, authenticated encryption, etc. If you use > LUKS2 and offload the volume to the kernel keyring though, please bear > in mind that key files lying on disk are readable by userspace, so the > threat model changes slightly. > > In practice, if you go for key files, the following crypttab(5) snippet > should work with your setup, assuming /dev/sda1 is a LUKS1 device > holding /boot and /dev/sda2 is a LUKS1/LUKS2 device holding / (possibly > with a Logical Volume in between). > > sda1_crypt /dev/sda1 /etc/keys/boot.key luks,key-slot=1 > sda2_crypt /dev/sda2 /etc/keys/root.key luks > > (See the note about key slots in the document you linked.) And for > /etc/cryptsetup-initramfs/conf-hook: > > KEYFILE_PATTERN="/etc/keys/root.key" > > So 1. at GRUB stage you unlock /dev/sda1 interactively; 2. at initramfs > stage /dev/sda2 is unlocked non-interactively using the key file copied > to the initramfs image from /etc/keys/root.key; 3. later systemd unlocks > /dev/sda1 non-interactively using the key file /etc/keys/boot.key. > > I'll see if I can clarify the document. > > Hope this helps,
It does clearly helps! $ systemctl status systemd-cryptsetup@sda1_crypt | cut -d " " -f 5- systemd-cryptsetup[352]: Failed to activate with key file '/etc/keys/boot.key': No such file or directory I don't understand why I get this error, the file is there and generated as suggested for 'root.key'. Any thoughts? I realy appriciate you walking me through this process. -- John Doe
