Affected component(s) or functionality
Qubes 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
configure qubes-u2f-proxy
Insert a yubikey 5 NFC into sys-usb (although this should be reproducible with any security key supporting openssh and u2f)
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.
Does HID need to be supported at all, or is it sufficient to only support the newer FIDO2 specification?
Is Python the best language for a re-implementation, or would Rust be preferable? The current code makes heavy use of ctypes to parse C structs, but that is unsafe. Rust could make short work of such parsing, either via the zerocopy crate or my own qubes-castable.
Qubes OS version R4.1
Affected component(s) or functionality Qubes 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
ssh-keygen -t ecdsa-sk
Expected behavior The yubikey should prompt for touch and the key should be generated.
Actual behavior
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 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 issues none