I don’t know why it does not work in your case. The articles you linked seem reasonably accurate and are similar to the one I’m currently writing.
In short:
FYI, Alexander’s article has been published:
Great to see that the guide is completed. @w4tsn thought I should have got it to work. What seems to have happened is that there is a way that I either changed the Yubikey programming so that it is no longer recognizable in lsusb (“Yubikey not found”) or there is a way to remotely deprogram Yubikeys. The Yubikey was fully functional at first. Learning about the difference between HMAC-SHA1 (which Yubikey C Bio does not have) and FIDO 2FA (which has to do with confirming synchronized timing as I understand that) was interesting.
Precisely how did you configure? I mentioned earlier that there a differences between the guide and the structure I am looking at on my system. You might unpack this but I am still at the point of putting the article into practice. Like I said, I don’t know why my key goes unrecognized by the Authenticator and lsusb/lspci when it was working fine before. Last thing I had it plugged into was login.gov, which must be the vector, and now it is inert. How is that possible?
In response to the article, first I should mention that the type of Yubikey (C Bio) might be what is causing the difficulty. C Bio cannot be reset to factory defaults according to the company. The guides I referred to above didn’t use clevis. There are probably either details I have to work out that are not discussed in the more non-specific level of the guides or C Bio has particularities.
This topic is being discussed on Qubes Forum. Is F32 capable of locking LUKS with FIDO U2F?
It looks like the question has been answered before on that same forum:
How can we test from Dom0 terminal in Qubes R4.2 if this is still an obstacle? I believe Dom0 is now updated to F37 or F38 in latest.
Getting crypttab correct requires some attention.
Boot parameters and UUID for systemd-crypt
††***********************
The missing piece might be in systemd-cryptsetup-[generator](https://man.archlinux.org/man/systemd-cryptsetup-generator.8.en).
“If /etc/crypttab exists, only those UUIDs specified on the kernel command line will be activated in the initrd or the real root.”
The directions published did not mention this step which should be required for any U2F regardless of manufacturer. LUKS naming in GRUB/systemd boot has to match with systemd-crypt.
rd.luks= X
I don’t use the cryptsetup service, so I’m not sure how it works, but I would think you should be able to edit /etc/crypttab from that emergency shell (though you may have to use vi) and then restart the systemd-cryptsetup@-dev-sda3.service service and exit the shell to continue on.
If that works, you will need to re-edit /etc/crypttab once you get back to your full OS and then regenerate your initramfs so that the corrected /etc/crypttab file will be used on the next boot. (The /etc/crypttab file that you see when your system is fully booted is actually a different copy from the one in the initramfs image that is used when your system boots. When you run dracut -f, it copies the one from your running system into a new initramfs image that is stored under /boot.)
Been through TSA twice since last reply and my computer still works. More interested in preventing unauthorized access to the device if I leave it at home when I can’t protect it from evil maids who (impossibly?) can break zxcvbn “Centuries” 4 passwords or preform cold boot attacks.
Bringing together input from multiple sources since then, I think I have to start by editing crypttab back to the original line (which might be slightly difficult because I didn’t record the default) then re-start the systmd cryptsetup service and exit the shell. If it boots normally, then, only from full terminal can I try re-editing crypttab again. This will get very tedious if my next attempt at disk naming is not correct and I have to cycle through again. There is no way to do all this just from emergency shell, right?
Ok. Now as far as I can tell, the crucial part is the disk nomenclature.
bpreto has
nvme0n1p3_crypt UUID=xxx
I have
uuddev/sda3 /dev/disk/by-uuid/xxx
for line start in crypttab
udev has symbolic links (# file *) that need to match I think.
From shell I can’t get to boot parameters with GRUB_CMDLINE=rd.luks.uuid=luks-machine-id. I am not sure if I should name the two disk “aliases” with some part of boot parameters like rd.luks. Trial and error will be very time consuming since all the commands can’t be done from emergency shell and everything has to be cycled again. @w4tsn 4wtsn
R.I.P. System 76 - you will be missed
