SSH resident key creating fails once fido2 pin is set

Nitrokeys FIDO2 / Nitrokey 3
#1

I use Ubuntu 20.04 (OpenSSH 8.2), Nitrokey 3C NFC (v1.3.1)/Nitropy (0.4.36).
While investigating my new key, I run into one particular interesting issue.

I managed to create a non-resident key using the command:
ssh-keygen -vvv -t ecdsa-sk -f ~/.ssh/id_ecdsa_sk

Furthermore I also managed to create a resident key:
ssh-keygen -t ed25519-sk -Oresident -Oapplication=ssh:test -f /tmp/test

In order to view my new key, I had to set a pin - after setting the pin it’s not possible to create another resident key anymore:
a1rwulf@a1rwulf-nb:~/.ssh$ ssh-keygen -vvv -t ed25519-sk -Oresident -Oapplication=ssh:test2 -f /tmp/test2
Generating public/private ed25519-sk key pair.
You may need to touch your authenticator to authorize key generation.
debug3: start_helper: started pid=16661
debug3: ssh_msg_send: type 5
debug3: ssh_msg_recv entering
debug1: start_helper: starting /usr/lib/openssh/ssh-sk-helper
debug1: sshsk_enroll: provider “internal”, device “(null)”, application “ssh:test2”, userid “(null)”, flags 0x21, challenge len 0
debug1: sshsk_enroll: using random challenge
debug1: ssh_sk_enroll: using device /dev/hidraw0
debug1: ssh_sk_enroll: fido_dev_make_cred: FIDO_ERR_PIN_REQUIRED
debug1: sshsk_enroll: provider “internal” returned failure -3
debug1: ssh-sk-helper: Enrollment failed: incorrect passphrase supplied to decrypt private key
debug1: ssh-sk-helper: reply len 8
debug3: ssh_msg_send: type 5
debug1: client_converse: helper returned error -43
debug3: reap_helper: pid=16661
Enter PIN for authenticator:
debug3: start_helper: started pid=16662
debug3: ssh_msg_send: type 5
debug3: ssh_msg_recv entering
debug1: start_helper: starting /usr/lib/openssh/ssh-sk-helper
debug1: sshsk_enroll: provider “internal”, device “(null)”, application “ssh:test2”, userid “(null)”, flags 0x21, challenge len 0 with-pin
debug1: sshsk_enroll: using random challenge
debug1: ssh_sk_enroll: using device /dev/hidraw0
debug1: ssh_sk_enroll: fido_dev_make_cred: FIDO_ERR_INVALID_CBOR
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=16662
Key enrollment failed: invalid format

When no pin was set, I was prompted to tap the key, but since the pin is set, I’m only getting asked for the pin and then it aborts with above error.

Is this a known issue?

#2

I just tested this with my setup:

$ ssh-keygen -vvv -t ed25519-sk -Oresident -Oapplication=ssh:test2 -f /tmp/test2
Generating public/private ed25519-sk key pair.
You may need to touch your authenticator to authorize key generation.
Enter PIN for authenticator: 
debug3: start_helper: started pid=2962377
debug3: ssh_msg_send: type 5
debug3: ssh_msg_recv entering
debug1: start_helper: starting /usr/lib/openssh/ssh-sk-helper 
debug1: sshsk_enroll: provider "internal", device "(null)", application "ssh:test2", userid "(null)", flags 0x21, challenge len 0 with-pin
debug1: sshsk_enroll: using random challenge
debug1: sk_probe: 1 device(s) detected
debug1: sk_probe: selecting sk by touch
debug1: ssh_sk_enroll: using device /dev/hidraw0
debug1: ssh_sk_enroll: attestation cert len=564
debug1: ssh_sk_enroll: authdata len=251
debug1: main: reply len 1165
debug3: ssh_msg_send: type 5
debug3: reap_helper: pid=2962377
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /tmp/test2
Your public key has been saved in /tmp/test2.pub
The key fingerprint is:
SHA256:MwoIGqjn3LdMdgVXoNByoLpyuhYPHsAAMl9Z5EJSBRU lupe@alanya
The key's randomart image is:
+[ED25519-SK 256]-+
|= ..=BE+  ...    |
|+o +.o..o. .     |
|* . o .oo .      |
|++ o .   o       |
|+ + .   S .      |
| B o . . +       |
|o X . = .        |
| * . = o         |
|+.    o          |

This is using Ubuntu 22.10 (Kinetic Kudu) and Nitrokey firmware v1.4.0.

#3

Thanks for your test.
So it’s either the old SSH or the firmware - I’ll try it on a more recent OS and new firmware if necessary.

EDIT:
Looking at your log, it looks more like an issue with SSH.
Your SSH uses “with-pin” while mine doesn’t:

debug1: sshsk_enroll: provider "internal", device "(null)", application "ssh:test2", userid "(null)", flags 0x21, challenge len 0 with-pin

So I assume this got fixed in ssh, so I’ll try a more recent SSH as a first step.