Yubikey FIDO2 webauthn setup on linux

Software & Operating Systems Linux
,
1

I just got some yubikey 5 USB keys and I’ve been trying to set it up for webauthn (FIDO2) for authenticating with sites that support it.

Some system information:

  • OS: Mainline Arch Linux
  • DE/WM: DWM
  • Browser(s): Firefox, chrome, librewolf, brave

What I’ve tried

  • installing libfido2 (and setting udev rules as detailed in the readme)
  • verified FIDO2 is enabled on my yubikeys
  • installed yubioauth-desktop package
    • found webauthn showed as not supported unless run under sudo
  • found webauthn works when running Firefox under sudo (obviously not recommended)
  • I’m using yubico’s demo site for testing (Yubico demo website)
  • verified I have all the dependences installed for libfido2
  • enabled the pcscd.service and verified it is running (shows no errors)
  • did a full system update
  • rebooted after messing with udev rules
  • applied the udev rules file detailed here (and added the udev rule example provided in the readme for libfido2) https://support.yubico.com/hc/en-us/articles/360013708900-Using-Your-U2F-YubiKey-with-Linux

Has anyone gotten this to work? Is there something I’m missing? Any advice would be greatly appreciated!

2

Hmm. Sounds weird. I use my 5C with Firefox (Fedora) for some time now.

I can remember that I had some problems with the flatpak versions.

Do you get the firefox permission prompt when testing on the demo website?

3

So I don’t get the permission prompt on the site I posted (though it does show a dialogue as lf it’s trying to “listen” for the device) but do on another yubico page but same issue overall. It acts like it doesn’t register the yubikey unless run with admin privileges

Edit: version of Firefox I’m running doesn’t not appear to be the faltpak variant since none of the dependencies mention faltpak at all (installed the default arch Firefox package)

4

Additionally in the yubioath-desktop client it only shows webauthn as available on my keys when its run under sudo so i’ve also be checking that.

5

Well if it works as root I would suspect something is wrong with the udev rules. But this is kind of a rabbit hole with uaccess, systemd-logind, etc. (I could be completely wrong. I have no idea)

What I can tell you is that, I do not use the udev rules provided by them. My key 1050:0407 works out of the box with systemd-udev and the hwdb.
→ Did you try without the udev rules provided by them?

6

I did initially which is what lead me down this rabbit hole. I’ll try removing the udev rules and see anything changes.

Update: No change

7

For testing purposes you could also try to temporarily set the MODE in the udev rule to “0666” (instead of “0660”). → allowing all users

8

Excellent so that worked fine. I used the following udev rule and it works straight away.

KERNEL=="hidraw*", SUBSYSTEM=="hidraw", MODE="0666", GROUP="plugdev", ATTRS{idVendor}=="1050"

question, the group argument thats not talking about a user group is it?

UPDATE: ok turned out the group argument is a usergroup. It wasnt working before because the group did not exists, I created the group plugdev and added my user account to it and now everything is working with mode 0664!!

1 Like
9

Just as a note:

The modern recommended approach for systemd systems is to use a MODE of 660 to let the group use the device, and then attach a TAG named uaccess [3]. This special tag makes udev apply a dynamic user ACL to the device node, which coordinates with systemd-logind(8) to make the device usable to logged-in users.

https://wiki.archlinux.org/title/udev#Allowing_regular_users_to_use_devices

10

Thanks for that. I only have one user account that gets used so don’t think having dynamic user ACL is super important in this case, unless there are other benefits of doing it that way on a single user system.

Also thanks so much for your help!

Edit: so had to brush up on permission calcs. I’m going to try using 0660 and make sure that still works (it should at this point). Since it’ll increase security a bit (removing the ability to read from “others”)

Update: changed permissions to 0660 and all is still well. unless adding the dynamic user ACL provides some additional benefits I think we’re good at this point.