On F38 on Silverblue it was a little finicky as the key had to be plugged in when the browser was started, but it worked.
On F40 nothing happens. Tried Chrome, Chrome-unstable, the Firefox that came with the install and some other browsers - none query the key.
There was another article on using the key for login, that proposed installing various software but none of that made any difference, and it did not require this before.
I have a Solo V1 and it works fine on Firefox on Workstation 40, at least last night 
I suspect different hardware keys and APIs might be different, or Silverblue is doing something unexpected.
Funny you mention Silverblue. I was using an up to date Silverblue before installing F40 fresh, and the key was working. The reboot after installs was getting to be a bit much, hence the change.
I am using an Only Key because of the touch pad on top. It has worked well in place of a Yubikey. I’m not seeing the blue light that goes on when it negotiates. It appears the key is not being queried at all, so I don’t suspect an firmware issue. I think I will update the firmware and try it again …
As this may be a regression in F40 I changed the tag.
Have you tried Fedora Chromium? Just as another browser to try and not forget 
this may be a udev rule issue, but we need more info. I dont know much about these keys, but maker and model, and probly lsusb or something?
Maybe the journalctl log while plugging it in?
journalctl -f
If the firefox is a flatpak, Have you considered pass the USB port to the Flatpak environment? Giving it access to the Key?
I installed Debian 12 on a VM because the ONLYKEY app runs on it, so I tried Firefox and Chrome there. Both are native installs (i.e. not flatpak). The app finds the key, as does lsusb. After the firmware update on the key, I get error messages on journalctl -f for Chrome.
In all cases the key does not give a blue light, hence no indication a button should be pushed, and pushing a button anyway does nothing.
Firefox is native on both D12 and F40, and behaves as before, with the dialog box appearing then a moment later disappearing. There is an error message:
"
There was a problem.
Try using your security key again or try another way to verify it’s you
"
There is nothing output on the console. Logging information is very general about socket traffic. There is nothing written to the journal.
Chrome is more informative after the firmware update. The results are the same for D12 native, and F40 flatpack. The key dialog appears and does not go away (unlike for FF) as though it is waiting. It hangs there (unlike FF).
This is the journalctl output:
journalctl:
Chrome installed directly Debian 12:
Jul 21 02:22:42 M1 google-chrome.desktop[3808]:
[3801:3801:0721/022242.798829:ERROR:device_event_log_impl.cc(196)]
[02:22:42.798] FIDO: get_assertion_request_handler.cc:767 Ignoring status 50
from usb-1d50:60fc
Chrome flatback F40:
Jul 21 09:43:15 Vivobook12 kernel: usb 1-3: new full-speed USB device number 39 using xhci_hcd
Jul 21 09:43:15 Vivobook12 kernel: usb 1-3: New USB device found, idVendor=1d50, idProduct=60fc, bcdDevice= 1.00
Jul 21 09:43:15 Vivobook12 kernel: usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jul 21 09:43:15 Vivobook12 kernel: usb 1-3: Product: ONLYKEY
Jul 21 09:43:15 Vivobook12 kernel: usb 1-3: Manufacturer: CRYPTOTRUST
Jul 21 09:43:15 Vivobook12 kernel: usb 1-3: SerialNumber: 1000000000
Jul 21 09:43:15 Vivobook12 kernel: input: CRYPTOTRUST ONLYKEY as /devices/pci0000:00/0000:00:08.1/0000:04:00.3/usb1/1-3/1-3:1.0/0003:1D50:60FC.0052/input/input37
Jul 21 09:43:15 Vivobook12 kernel: hid-generic 0003:1D50:60FC.0052: input,hidraw3: USB HID v1.11 Keyboard [CRYPTOTRUST ONLYKEY] on usb-0000:04:00.3-3/input0
Jul 21 09:43:15 Vivobook12 kernel: hid-generic 0003:1D50:60FC.0053: hiddev96,hidraw4: USB HID v1.11 Device [CRYPTOTRUST ONLYKEY] on usb-0000:04:00.3-3/input1
Jul 21 09:43:15 Vivobook12 kernel: hid-generic 0003:1D50:60FC.0054: hiddev97,hidraw5: USB HID v1.11 Device [CRYPTOTRUST ONLYKEY] on usb-0000:04:00.3-3/input2
Jul 21 09:43:15 Vivobook12 mtp-probe[28609]: checking bus 1, device 39: "/sys/devices/pci0000:00/0000:00:08.1/0000:04:00.3/usb1/1-3"
Jul 21 09:43:15 Vivobook12 mtp-probe[28609]: bus: 1, device: 39 was not an MTP device
Jul 21 09:43:15 Vivobook12 systemd-logind[1048]: Watching system buttons on /dev/input/event7 (CRYPTOTRUST ONLYKEY)
Jul 21 09:43:15 Vivobook12 mtp-probe[28624]: checking bus 1, device 39: "/sys/devices/pci0000:00/0000:00:08.1/0000:04:00.3/usb1/1-3"
Jul 21 09:43:15 Vivobook12 mtp-probe[28624]: bus: 1, device: 39 was not an MTP device
Jul 21 09:44:11 Vivobook12 com.google.Chrome.desktop[28095]: [2:2:0721/174411.809606:ERROR:device_event_log_impl.cc(196)] [17:44:11.809] FIDO: get_assertion_request_handler.cc:767 Ignoring status 50 from usb-1d50:60fc
after try again:
Jul 21 09:46:43 Vivobook12 com.google.Chrome.desktop[28095]: [2:2:0721/174643.612334:ERROR:device_event_log_impl.cc(196)] [17:46:43.612] FIDO: get_assertion_request_handler.cc:767 Ignoring status 50 from usb-1d50:60fc
I have not yet passed the key through to flatpak, but I am trying to figure it out now, and will report back.
Yes I tried Chromium on F40 yesterday, and it did not query the key either.
Hello, I did this to run F40 Google Chrome with access to all devices. The results are similar, though the message went to the terminal rather than to the system journal:
> flatpak run --device=all com.google.Chrome
[0721/111540.639845:WARNING:chrome_main_linux.cc(80)] Read channel stable from /app/extra/CHROME_VERSION_EXTRA
[0721/111540.777837:WARNING:chrome_main_linux.cc(80)] Read channel stable from /app/extra/CHROME_VERSION_EXTRA
Gtk-Message: 11:15:40.818: Failed to load module "canberra-gtk-module"
Gtk-Message: 11:15:40.818: Failed to load module "pk-gtk-module"
Gtk-Message: 11:15:40.819: Failed to load module "canberra-gtk-module"
Gtk-Message: 11:15:40.819: Failed to load module "pk-gtk-module"
[2:2:0721/111541.059136:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.ScreenSaver.GetActive: object_path= /org/freedesktop/ScreenSaver: org.freedesktop.DBus.Error.NotSupported: This method is not part of the idle inhibition specification: https://specifications.freedesktop.org/idle-inhibit-spec/latest/
[58:58:0721/111550.293169:ERROR:gl_surface_presentation_helper.cc(260)] GetVSyncParametersIfAvailable() failed for 1 times!
Created TensorFlow Lite XNNPACK delegate for CPU.
[58:58:0721/111556.547177:ERROR:gl_surface_presentation_helper.cc(260)] GetVSyncParametersIfAvailable() failed for 2 times!
[58:58:0721/111624.292744:ERROR:gl_surface_presentation_helper.cc(260)] GetVSyncParametersIfAvailable() failed for 3 times!
[2:2:0721/111639.077434:ERROR:device_event_log_impl.cc(196)] [11:16:39.077] FIDO: get_assertion_request_handler.cc:767 Ignoring status 50 from usb-1d50:60fc
The last message appears when the key is queried.
I confirmed today that the security key works well in F38 - so this is also a work around:
Download F38 iso from:
https://archives.fedoraproject.org/pub/archive/fedora/linux/releases/38/Workstation/x86_64/iso/
Use virt-manager to install it on a VM, and pass it the usb device that is the security key. A direct install would also work.
Do not do updates, but run the firefox that comes with the install, and it works fine with security keys When presented with the security key challenge the ONLYKEY blue light comes on, and upon pressing the button, the site issuing the challenge accepts it.
Unfortunately, running an outdated web browser is probably too much of a security risk to be considered a viable workaround. Does the problem occur if you update just the browser and nothing else (or as little else as possible, i.e. sudo dnf update firefox)?
Updating firefox breaks it.
There was a problem
Try using your security key again or try another way to verify it’s you
Was it just firefox that you updated (it didn’t pull in any other updates)? Does downgrading firefox back to the original version with sudo dnf downgrade firefox restore the functionality?
It was just firefox that I updated.
I was on the live F38 direct from the distro. Tested firefox, logged into a site with hardware key 2FA, and it worked. I pulled up a terminal and cut and pasted:
sudo dnf update firefox
Then ran firefox again and the key no longer worked. And now typing into the terminal:
sudo dnf downgrade firefox
After that finishes, closing firefox, reopening firefox. And yes indeed, now the key works again. (excuse me, cut and paste mistake there, now fixed)
I guess you’ve narrowed down where the problem is occurring then. 
The next thing would be to search Firefox’s issue reports to see if someone else has noted the problem (which seems like it would be likely since that is such an old version of Firefox).
Interesting how you isolated that to firefox then crossed to the forums. That makes sense.
Though on F40 it is also Chrome, Chrome-development, and Chromium. I have a flatpak of Edge, let me try that …
> flatpak run --device=all com.microsoft.Edge
key does not work for Edge either. So I had concluded the problem was F40. Now, what do all the browsers have in common other than the OS? 
I rather think the common element is your particular brand of security key. But either way you look at it, it doesn’t appear (at this point) to be a problem with Fedora Linux.
I see that the status was updated to “fix-optional” on that bugzilla, but I don’t see any mention of what the fix is. You might take your report there and see if you can get someone to hint at how to get your security key to work with the latest versions of Firefox.
Here in their literature:
Step 1 - Linux UDEV Rule
Linux requires a UDEV rule in order for non-root users to be able to communicate with USB devices. Installing the OnlyKey App .deb will also install the UDEV rule automatically or to install manually:
Go to https://github.com/trustcrypto/trustcrypto.github.io/blob/master/49-onlykey.rules and download or create a copy of the file named 49-onlykey.rules into the Linux directory: /etc/udev/rules.d/.
Use the command udevadm control --reload-rules && udevadm trigger or restart system for changes to take effect
As things were working, I had not searched for this before.
Copying their udev file to the location suggested, followed by the commands they suggested, made no difference. I guess the next step is to ask on their forum.