The U2F support in Firefox (122.0, FreeBSD 14.0-STABLE/amd64) is very unreliable. Sometimes it works, sometimes the "Touch your security key" popup appears, but Firefox fails to talk to the U2F security key, i.e., the security key doesn't flash. This can be reproduced at the https://webauthn.io/ demo site. I use ssh with U2F-backed keys (ed25519-sk) all the time, and that is completely reliable, so the problem is due to Firefox.
seems to work for me, I've now gone through the dance at webauthn.io several times without glith (but then I'm still on 13.2 and already on 123, maybe that makes a difference?)
(In reply to Christoph Moench-Tegeder from comment #1) The problem already existed before I switched from FreeBSD 13 to 14 around Christmas. I think since then there has been at least one upstream Firefox fix that addressed U2F issues, but it didn't help. I don't know about Firefox 123. I just tried it a bunch of times: 4 out of 6 worked. It's just very random. Does anybody use this productively? I would love to ktrace a failure so see whether that provides any clue, but how do I find out which Firefox process to trace? (Meanwhile I use ssh with U2F a two-digit number of times every day and it works 100%.)
(In reply to Christian Weisgerber from comment #2) > Does anybody use this productively? Good question - top of my head I remember very few (single-digits) sites offering full U2F, and those are really not my most-frequented ones. (I use one of the blue Yubikeys from a few years back as my primary U2F-device). >I would love to ktrace a failure so see whether that provides any clue, but how do I find out which Firefox process to trace? There's about:processes > (Meanwhile I use ssh with U2F a two-digit number of times every day and it works 100%.) Do matters improve when SSH is not accessing the key? I use "traditional" ssh keys from the "auth" slots of some USB/smartcard fobs (the blue yubikey doesn't store keys, so...), so I can't have any conflict there.
(In reply to Christoph Moench-Tegeder from comment #3) The communication with the FIDO/U2F authenticator happens in the main firefox process. I ktraced this for both the working and non-working case. In both cases, firefox successfully opens the correct /dev/uhidN device, initializes the Client-to-Authenticator Protocol, queries the authenticator for its supported features, and receives the response. All of this happens identically in both cases. In the non-working case, firefox then stops: it closes the fd, and exits the thread. In the working case, firefox proceeds to exchange cryptographic messages with the authenticator, and eventually closes the fd, and exits the thread. There is nothing in the initial communication with the authenticator that would explain the different behavior. The authenticator's responses are identical.
I typically have three /dev/uhidN devices on that machine. One from the Yubikey authenticator, two from unrelated USB peripherals. Looking at the ktrace results, I see that firefox spawns a parallel thread for each of my /dev/uhid[0-2] device nodes to check whether the device is an authenticator. The threads probing the wrong devices exit quickly, the third one proceeds to establish communications with the authenticator. I wonder whether the results from the threads are mixed up and there is effectively a race between threads for discovering the authenticator. The erratic behavior I observe would fit a race condition. I have now unplugged the other uhid devices, so there is only the single /dev/uhid0 for the authenticator, and so far I have been unable to reproduce the problem.