@marmarek I think I found the cause of the 3 password prompts (black “Q” luks page with Yubikey).
The first password is always wrong. Doesn’t matter if you type it correctly, it’s always wrong. Maybe a bad character buffer? Acts like an uninitialized buffer, or something initialized with junk. (Failing the password clears the buffer, and gives the second password prompt.)
The second password is the real password. It checks and gives a message about receiving a response from the yubikey and the luks drive being unlocked.
The third password prompt is a bug. It doesn’t matter what you enter, it is ignored. (I intentionally entered a bad password, it didn’t care.) But you must enter something to get past the prompt. Then the OS boots.
Update: Reconfirmed
The first prompt says “Disk password”. Just press enter. This password is ignored.
The prompt changes to “Password”. Enter the yubikey passphrase. (Received response from Yubikey. Luks device opened.)
The third prompt says “Disk password”. Type anything; it is ignored. Then the system boots.
Possibly related: if you enter the wrong yubikey passcode at the “Password” prompt, then no number of re-entering the passcode will permit you to login. It looks like it wrote a temp file and is failing to overwrite it with the re-entered passcode.
The solution is to hard-reboot and do it again.
Update: Grrr… this is inconsistent. Sometimes a second password works, but sometimes a bad password cannot be recovered. (File locking issue? Permissions? Uninitialized buffer? Where’s the source code for this?)
How I came up with the script:
There were instructions for using Yubikey on Qubes 4.0.x. They were manual “type the following”. All I did was automate those instructions.
Whatever broke Yubikey support happened when Qubes 4.1 came out.
So you followed the original instructions for Qubes 3.2 from this.
The mechanism for handling the auth is built into the dracut module that is built from those scripts. So if anything, something in 4.1 changed that probably has a new version that makes the script break.
You should probably submit an issue with the2nd’s ykluks repo.
Stores the path to a GRUB file in a variable called grub for future use (the name could be whatever, it happens that grub makes sense in this context when you’re used to using variables)
Prints exactly Converting /etc/default/grub to use yubikey. Uses the variable defined above to do that. If you’re reading this in color in the forum, you can notice in the snippet above how the color of $grub is different to indicate that a variable is in use. This kind of printing is only for you to be able to know what’s going on while the script runs, it will be printed in the terminal in which the script is executed.
Makes a copy of /etc/default/grub called /etc/default/grub.bak. The latter is a common naming scheme for backups. The idea is that /etc/default/grub will be edited, but if you later on want to revert those changes, you’ve got a copy of the original file and can do the opposite operation to overwrite the changes: cp /etc/default/grub.bak /etc/default/grub.
Read the contents of the file /etc/default/grub and pass them as text to the next step
in that text, replace all occurrences of rd.luks.uuid= by rd.ykluks.uuid= and pass the result as text to the next step
in that text, replace all occurrences of rd.qubes.hide_all_usb by rd.ykluks.hide_all_usb and replace the content of /etc/default/grub with the resulting text
Print exactly Generating new bootloader
Uses a program called grub2-mkconfig to generate a file called /boot/efi/EFI/qubes/grub.cfg. That’s a configuration file that GRUB uses to show entries you can boot from. From the logic of the script you can infer that the program grub2-mkconfig uses the contents of /etc/default/grub to generate the config file. If you change those and run the program again, you get a new config file. (grub2-mkconfig manual – it’s half a page long, worth a look!)
Prints exactly Generating new kernel
Runs a program called dracut with the -f option to generate something called an initial image that is used by the kernel. From the logic of the script, you can infer that the initial image that dracut generates is different when /boot/efi/EFI/qubes/grub.cfg has changed.
Here is the summary of what the dracut manual says (follow the link for more details):
dracut creates an initial image used by the kernel for preloading the block device modules (such as IDE, SCSI or RAID) which are needed to access the root filesystem.
Options
-f, --force
overwrite existing initramfs file.
That all depends on the previous steps. Is ykchalresp the only authentication method? I have a Yubikey C Bio and ykchalresp does not work, only FIDO2, I believe. How would you modify your directions for C Bio?
Since Qubes is building off of Fedora for base functions, it should be easy for you to tell me how modify the directions of the Fedora article to work on Qubes.
Disclaimer: I don’t know myself. That being said, searching about systemd-cryotenroll in the forum lead me to this post, that seems to suggest that performing the initial LUKS unlocking using FIDO2 during startup is not yet possible as of R4.1. Again, I may be reading that wrong, and that information might be incorrect, but I think you’ll find some information on the forum starting from there.
Dom0 is not F37 as of latest? Alexander’s article cited above is addressing current Fedora. FIFO2 authorization is possible with all series 5 keys. I am going to try it, but maybe I should get a non-bio Yubikey for ykchalresp since a lot of the complexity is already worked out smoothly and the script looks solid. But then anyone with the hardware key can unlock. They don’t need a fingerprint. So what is the point? Carrying the key is more portable? Its not like HEADS is verifying hardware measurements with a Purism key.
Then you could be right about not up for FIDO U2F, systemd cryptenroll, crypttab, and dracut . . . but all that has been around for awhile. F32 is not pre-systemd.
Dom0 can change it’s boot from GRUB to EFI which means systemd boot is possible.
But if Dom0 requires installation or updating, that is a problem. Update Manager asks me to update Dom0 but if that is compromised, all is lost so I don’t. FIDO U2F locking LUKS mught require networking access that bypasses even Update Manager security measures.
Probably should get a non-bio series 5 Yubikey with ykchalresp.
Do other keys like Nitro or Feitian have something like ykchalresp that can be installed in Work qube and connected to GRUB?