Currently U2F does not work with QubesOS : Support for USB composite (HID/U2F) devices via sys-usb · Issue #5287 · QubesOS/qubes-issues · GitHub
Is there any way (udev rule maybe) to disable the U2F personality and only keep the keyboard input one ?
It looks like this issue is from 2019. Are you running the latest v2.1.1 OnlyKey firmware?
Have you tried the steps listed here - Using OnlyKey with Qubes OS | Docs
Just tested with latest Firmware. Still not working but symptoms are a bit different than with previous beta fw : the key flashes blue once then green immediately with no time to touch it.
And yes I followed the instruction and the key works for the keyboard input part.
So for the steps listed here - Using OnlyKey with Qubes OS | Docs
What are the results of trying these steps? For example the steps include running this command which should work if your device is configured correctly.
If this works then USB communication works. The next thing to check would be if you are running an older browser that doesn’t support FIDO2.
Qubes uses a u2f-proxy system.
Using the OnlyKey directly attached to the VM running the browser works but this is not the intented flow. The OnlyKey app works when the key is attached to the app VM .
Other Fido keys works with the u2f proxy.
Thanks for helping.
I did find an issue here that looks related - U2F support for Trezor · Issue #16 · QubesOS/qubes-app-u2f · GitHub
It seems Trezor and Yubikey were also not working with u2f-proxy back in 2019 and this issue has still not been resolved. Also u2f-proxy has not been updated in 4 years and uses an old discontinued yubico u2f library, so u2f-proxy does not support FIDO2. The only option to support FIDO2 security key would be if the maintainers add support or to not use u2f-proxy and instead use an alternative like described in our document here Using OnlyKey with Qubes OS | Docs
The issue seems to be that the u2f-proxy only polls once for the user to press button on device. So unless you press the button immediately u2f-proxy just stops polling. That is why you only see your device flash blue for a short time and then stop.
Looking at the sequence of events with a Solokey I see multiple polls of u2f-proxy until key pressed.
If implementations are similar between Solokey and Onlykey I would expect same result. I will dig into the code of the proxy and check if there are some exclusions.
Check on my QUbes 4.0 install :
hid_transport.py explicitly manages OnlyKey :
Line 58 : (0x1d50, 0x60fc), # OnlyKey U2F
I managed to get it working partially : in fact the key will blink blue multiple times but :
- It takes up to 18s to see the first blue flash (sometimes it occurs immediately)
- the next flash can take up to 10s to appears
Being ready for the second blue flash allows me to register. Next I tried to login (on token2.com) but got now answer from the key (no blue flash).
While everything ended working as expected with fedora-35 based qubes (thanks to undetermined update), the U2F proxy stopped working again for Only key after upgrading dom0 to QUbes 4.1.
When U2F register is send from a qubes VM nothing happens anymore on the onlykey (not even blue blinking). I checked the udev rules, reinstalled every involed u2f packages with no success.
With a solokey no issue.
Anyone else having the same issue?
Here’s the trace :
Jul 29 18:11:24 sys-usb u2f.Register+-work: File "/usr/lib/python3.10/site-packages/u2flib_host/hid_transport.py", line 214, in _read_resp
Jul 29 18:11:24 sys-usb u2f.Register+-work: raise exc.DeviceError("Invalid response from device!")
Jul 29 18:11:24 sys-usb u2f.Register+-work: u2flib_host.exc.DeviceError: Invalid