yubikey-luks initramfs unlock script does not work on Ubuntu 24.04 LTS

[random578036896547]

Hi, on clean new installation of Ubuntu 24.04 yubikey-luks initramfs unlock script does not work.

after insatlation (sudo apt-get install yubikey-luks -y) I am able to enroll keys in key slots. (both for default system partition (/dev/nvme0n1p3), and for external USB pen drive I used for test /dev/sda3). with yubikey-luks-enroll. I am able to use yubikey-luks-open for external pendrive (/dev/sda3) I used for testing. So making key slots and using chalange-responses from yubi keys works. However after reboot of system OS in LUKS unlock screen, no yubikey-luks welcome text is shown and unlock for keyslots containing enrolled keys are not working. Only those I made with luksAddKeys and therefore with passwords only are working. I am using same laptop as for previous 18.04-23.10 where everything worked ok. (Dell XPS 13 9350) Did not work first time (depending on automaticall add keyscript to crypttab - that worked for me before) Did not work after manual sudo update-initramfs -u Did not work after adding to /etc/crypttab cryptroot /dev/nvme0n1p3 none luks,keyscript=/usr/share/yubikey-luks/ykluks-keyscript and doing sudo update-initramfs -u again. Both yubikeys NFC5c I have are initialized for ch-response (ykpersonalize -2 -ochal-resp -ochal-hmac -ohmac-lt64 -oserial-api-visible) Thanks in advance for any advice, thx.

[Vincent43]

Do you have cryptsetup-initramfs package installed?

Does sudo update-initramfs -u shown any warnings/errors?

Can you unpack created initramfs and check if /sbin/ykluks-keyscript, /usr/bin/ykchalresp, /usr/bin/ykinfo, /usr/bin/sha256sum and /etc/ykluks.cfg does exist?

Also does passing cryptoptions=target=cryptroot,source=/dev/nvme0n1p3,keyscript=/sbin/ykluks-keyscriptin boot cmdline make any difference?

[random578036896547]

Hi,

ad) cryptsetup-initramfs yes, it is installed in version: (2:2.7.0-1ubuntu4)

ad) sudo update-initramfs -u update-initramfs: Generating /boot/initrd.img-6.8.0-35-generic cp: warning: behavior of -n is non-portable and may change in future; use --update=none instead

ad) unmkinitramfs /boot/initrd.img-$(uname -r) initramfs/ after unpacking i have 4 folders:

main, early, early2, early3 folder main contains all mentioned files (/sbin/ykluks-keyscript, /usr/bin/ykchalresp, /usr/bin/ykinfo, /usr/bin/sha256sum and /etc/ykluks.cfg), they seem to have valid content and config /etc/ykluks.cfg does change accordingly when I for example change welcome text in master config and call sudo update-initramfs -u

ad)cryptoptions=target=cryptroot,source=/dev/nvme0n1p3,keyscript=/sbin/ykluks-keyscript same outcome (no welcome text, not working in LUKS unlock screen)

[Vincent43]

Ok, so what exactly happens when you boot the OS and want to decrypt the drive? what is shown on the screen?

[random578036896547]

(before and after I try to enter pasword for yubikey chalenge-response keyslots, pasword-only keyslots work ok.)

[Vincent43]

Does it fallback to console mode when you hit Esc key repeatedly while showing this screen?

yubikey-luks welcome message is Please insert yubikey and press enter or enter a valid passphrase" on your photos there is different text, looks like something else is running than yubikey-luks?

[random578036896547]

I attached print screen after Esc from my laptop. I do not think that RMRR error has any consequence to yubikey-luks and to test it I took entirely different system (Desktop) and made new clean installation of 24.04 with only default values (only exception to that is using LUKS encrypted disk via installer instead of default non encrypted one.) Outcome was same issue and no errors on the other system, so I would expect that this affects all new Ubuntu 24.04 installations.

[Vincent43]

It indicates yubikey-luks isn't started for some reason

[Vincent43]

I tested ubuntu 24.04 and didn't observe any change of yubikey-luks initramfs script than before.

[random578036896547]

So you were able use yubikey-luks initramfs script on new install of 24.04? I took yet another system today (NUC 6i5syh) did clean new default install (except disk is LVM encrypted obviously) both with 24.04 and 24.10, did only apt-get install yubikey-luks -y and rebooted. None of 3 physical systems an one VM I tested worked.

[Vincent43]

I did upgrade from 22.04. I don't see why it would be different on fresh installation - initramfs is created against 24.04 tooling.

I also don't see similar bugreports for ubuntu or debian made by other users. I guess this one is yours.

Since there is no trace yubikey-luks is running in initramfs and you see it being part of created initramfs the only explanation I can made is for some reason you boot with different kernel+initramfs image than what's created. What's the mount-point of your EFI partition? Is it mounted while you're running system?

You may add init=/bin/sh to cmdline which will boot into shell and then you may check again that all yubikey-luks files are avalaible in running initramfs image.

[lhhel9l3]

I have the same issue with a fresh xubuntu 24.04 install using yubikey-luks on a dell laptop. Something is broken here for fresh installs.

[mijofa]

I'm also seeing this issue with Debian 12. I note that the Debian crypttab manpage indicates the keyscript= option is Debian specific.

This option is specific to the Debian crypttab format. It's not supported by systemd.

Is this perhaps getting a little deprecated?

I tried adding the cmdline arguments, no joy. I have not rebooted with modified crypttab because when I modified crypttab and ran update-initramfs -u I got an error that makes me concerned it wouldn't fallback on the standard decryption key usage:

update-initramfs: Generating /boot/initrd.img-6.1.0-26-amd64 cryptsetup: ERROR: nvme0n1p3_crypt: invalid value for 'keyscript' option, skipping

As far as I can tell, it's simply not even trying to run ykluks-keyscript.

For the sake of completeness, here's the original crypttab line::

nvme0n1p3_crypt UUID=df8dd885-d156-407c-ba9f-3d071f7ff400 none luks,discard

This is the modified one:

nvme0n1p3_crypt UUID=df8dd885-d156-407c-ba9f-3d071f7ff400 none luks,discard,keyscript=/sbin/ykluks-keyscript

And this is the cmdline argument I tried with:

cryptoptions=target=nvme0n1p3_crypt,source=UUID=df8dd885-d156-407c-ba9f-3d071f7ff400,keyscript=/sbin/ykluks-keyscript

[Vincent43]

Is this perhaps getting a little deprecated?

It was always Debian/Ubuntu specific.

This is the modified one:

nvme0n1p3_crypt UUID=df8dd885-d156-407c-ba9f-3d071f7ff400 none luks,discard,keyscript=/sbin/ykluks-keyscript

keyscript path is wrong. See instructions. The crypttab and cmdline paths are different

[Vincent43]

I noticed one thing that may help - please try adding initramfs option into /etc/crypttab like: <name> <source> none luks,initramfs,keyscript=/usr/share/yubikey-luks/ykluks-keyscript

[mijofa]

This is the modified one: nvme0n1p3_crypt UUID=df8dd885-d156-407c-ba9f-3d071f7ff400 none luks,discard,keyscript=/sbin/ykluks-keyscript

keyscript path is wrong. See instructions. The crypttab and cmdline paths are different

Gah! So it is, that has resolve the issue, sorry about that.

I noticed one thing that may help - please try adding initramfs option into /etc/crypttab like

It worked for me before doing this, but I added it anyway and nothing got worse.

[Vincent43]

@random578036896547 @lhhel9l3 could you test solution from https://github.com/cornelinux/yubikey-luks/issues/95#issuecomment-2462174094

[lhhel9l3]

@random578036896547 @lhhel9l3 could you test solution from #95 (comment)

Yeah that worked, thanks. It would be great if you could publish the fix in the ubuntu package so it doesn't require manual steps next time

[random578036896547]

success, after manual edit of /etc/crypttab dm_crypt-0 UUID=myUUID none luks,initramfs,keyscript=/usr/share/yubikey-luks/ykluks-keyscript it works! BTW: UUID can be found for example by ls -lha /dev/disk/by-uuid

[Vincent43]

Yeah that worked, thanks. It would be great if you could publish the fix in the ubuntu package so it doesn't require manual steps next time

If it's initramfs part that fixed it for you then the only fix we can do is updating instructions. Can you confirm that identical setup with initramfs line in /etc/crypttab works and without doesn't?