[qubes-users] U2F Proxy Support for OpenSSH / python-fido2

qboser · October 8, 2022, 9:00pm

Hello!

the U2F proxy supports browsers according to the documentation:

Approximately how far in the future will it support ssh as well?

Github issues:

github.com/QubesOS/qubes-issues

Allow OpenSSH to use the Qubes U2F Proxy

opened 08:24AM - 24 Mar 21 UTC

fmeef

T: enhancement P: default C: usb proxy

**Qubes OS version** R4.1 **Affected component(s) or functionality** Qube…s U2F proxy and openssh client. **Brief summary** Openssh 8.2 should be able to generate keys that use challenge-response security keys supporting u2f and FIDO2. While theoretically openssh can use any security key by loading a custom middleware implementation, the built-in implementation currently only supports FIDO2 over usb without HID encapsulation. This breaks the qubes U2F proxy, which only uses HID encapsulated FIDO1/U2F. An example of trying to generate an ecdsa-sk key (note this also fails with ed25519-sk) **How Reproducible** This bug occurs every time an openssh key supporting security keys is generated **To Reproduce** 1. configure qubes-u2f-proxy 2. Insert a yubikey 5 NFC into sys-usb (although this should be reproducible with any security key supporting openssh and u2f) 3. run `ssh-keygen -t ecdsa-sk` **Expected behavior** The yubikey should prompt for touch and the key should be generated. **Actual behavior** ``` ssh-keygen -vvv -t ecdsa-sk -C "secretkey-yubiky" Generating public/private ecdsa-sk key pair. You may need to touch your authenticator to authorize key generation. debug3: start_helper: started pid=968 debug3: ssh_msg_send: type 5 debug3: ssh_msg_recv entering debug1: start_helper: starting /usr/libexec/openssh/ssh-sk-helper debug1: sshsk_enroll: provider "internal", device "(null)", application "ssh:", userid "(null)", flags 0x01, challenge len 0 debug1: sshsk_enroll: using random challenge debug1: sk_probe: 0 device(s) detected debug1: ssh_sk_enroll: failed to find sk debug1: sshsk_enroll: provider "internal" returned failure -1 debug1: ssh-sk-helper: Enrollment failed: invalid format debug1: ssh-sk-helper: reply len 8 debug3: ssh_msg_send: type 5 debug1: client_converse: helper returned error -4 debug3: reap_helper: pid=968 Key enrollment failed: invalid format ``` **Screenshots** see above log **Additional context** This is reproducible with a yubikey 5 NFC connected over usb. The yubikey works fine if the ssh key is generated on sys-usb. The issue is only with the u2f proxy **Solutions you've tried** Using PVusb to attach the yubikey to the VM works, but that is less secure than u2f proxy. **Relevant [documentation](https://www.qubes-os.org/doc/) you've consulted** https://www.qubes-os.org/news/2018/09/11/qubes-u2f-proxy/ https://github.com/QubesOS/qubes-app-u2f/issues **Related, [non-duplicate](https://www.qubes-os.org/doc/reporting-bugs/#new-issues-should-not-be-duplicates-of-existing-issues) issues** none

github.com/QubesOS/qubes-issues

Switch from python-u2flib-host to python-fido2

opened 01:41PM - 05 Dec 19 UTC

SaswatPadhi

T: enhancement C: other P: major

**The problem you're addressing (if any)** The [python-u2flib-host](https://git…hub.com/Yubico/python-u2flib-host) project page says that it has been superseded by [python-fido2](https://github.com/Yubico/python-fido2). **Where is the value to a user, and who might that user be?** Issue #5400 reports that Google Titan U2F keys were not recognized by Qubes. I have had similar experience with OnlyKey. The solution in both cases was a patch that adds a new device to the python-u2flib-host library, but [qubes-python-u2flib-host](https://github.com/QubesOS/qubes-python-u2flib-host) still seems to be using the 3.0.3 release (from > 1.5 years ago). Since python-fido2 is still in beta stage, as the authors warn on the project page, may be qubes-python-u2flib-host could use the latest python-u2flib-host sources for the time being and switch to python-fido2 once it's stable?

thanks!