"resident" OpenSSH-sk keys not working (yet?)

[PartTimeDataScientist]

I am trying to use the solo2 for SSH authentication making use of the FIDO2 feature introduced with OpenSSH 8.2. While I can successfully generate and use an ed25519-sk key using
ssh-keygen -t ed25519-sk -Oapplication=ssh:user.name

trying to store the "keys" on the device (for easier switching between computers) using
ssh-keygen -t ed25519-sk -Oresident -Oapplication=ssh:user.name

fails with a Windows Security message saying This security key can't be used. Please try a different one.

Question: Is this a hardware limitiation, a not yet implemented feature or a bug?

My system: Windows 11 - OpenSSH_for_Windows_8.9p1, LibreSSL 3.4.3

[d4g]

I had the same issue, trying out the new putty-cac with fido2 support:
NoMoreFood/putty-cac#57

Seems to be not working yet.

[stintel]

I am actually able to generate a resident key:

$ ssh-keygen -v -t ecdsa-sk -O resident -f /tmp/id_ecdsa_sk
Generating public/private ecdsa-sk key pair.
You may need to touch your authenticator to authorize key generation.
Enter PIN for authenticator:
debug1: start_helper: starting /usr/lib64/misc/ssh-sk-helper
debug1: sshsk_enroll: provider "internal", device "(null)", application "ssh:", 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/hidraw11
debug1: ssh_sk_enroll: attestation cert len=642
debug1: ssh_sk_enroll: authdata len=316
debug1: main: reply len 1386
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /tmp/id_ecdsa_sk
Your public key has been saved in /tmp/id_ecdsa_sk.pub
The key fingerprint is:
SHA256:nw7Bi5URKIHo5OTWBb1TwOEUjwufwW+M4icvHionyyg stijn@taz
The key's randomart image is:
+-[ECDSA-SK 256]--+
| . o=*+..        |
|.o. =++. .       |
|* ...*o..        |
| = .ooB. o       |
|.  . =.+S        |
|  . . .o + .     |
|   + .. o o      |
|E o.=    o       |
|=*....    .      |
+----[SHA256]-----+

For comparison, the same process with a Yubikey 5 gives similar output:

$ ssh-keygen -v -t ecdsa-sk -O resident -f /tmp/id_ecdsa_sk
Generating public/private ecdsa-sk key pair.
You may need to touch your authenticator to authorize key generation.
Enter PIN for authenticator:
debug1: start_helper: starting /usr/lib64/misc/ssh-sk-helper
debug1: sshsk_enroll: provider "internal", device "(null)", application "ssh:", 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/hidraw10
debug1: ssh_sk_enroll: attestation cert len=705
debug1: ssh_sk_enroll: authdata len=164
debug1: main: reply len 1146
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /tmp/id_ecdsa_sk
Your public key has been saved in /tmp/id_ecdsa_sk.pub
The key fingerprint is:
SHA256:ssAN9vYq19q0jdfyulyxKNhf1q5vrce0Xik91HtKT2w stijn@taz
The key's randomart image is:
+-[ECDSA-SK 256]--+
|                 |
|                 |
|    o            |
|   o +          .|
|    o = S   .  ..|
|     o *   . +o.+|
|      o.= ..=.oOE|
|    . .+.Bo+.oo*B|
|     oo.+.*=o+*+.|
+----[SHA256]-----+

Unfortunately, loading the key does not work:

$ ssh-add -K -v
Enter PIN for authenticator:
debug1: start_helper: starting /usr/lib64/misc/ssh-sk-helper
debug1: sshsk_load_resident: provider "internal", have-pin
debug1: sk_probe: 1 device(s) detected
debug1: sk_probe: selecting sk by touch
debug1: ssh_sk_load_resident_keys: trying /dev/hidraw9
debug1: read_rks: device /dev/hidraw9 does not support resident keys
debug1: main: reply len 4

The same happens with ed25519-sk keys.
Tested on Gentoo with OpenSSH 8.8p1 and Fedora 34 with OpenSSH 8.6p1.

[d4g]

Which firmware are you running?

[stintel]

1:20200101.9

[PartTimeDataScientist]

Just tried again after installing the newest firmware but still no luck...

Downloading latest release from https://github.com/solokeys/solo2/
Fetched firmware version 1:20200101.9
Tap button on key to confirm, or replug to abort...
LPC55 Bootloader detected. The LED should be off.
Writing new firmware...
Done. Rebooting key. The LED should turn back on.
PS D:\> ssh-keygen -vvv -t ed25519-sk -O resident -f D:\id_ed25519_solo2-sk-test
Generating public/private ed25519-sk key pair.
You may need to touch your authenticator to authorize key generation.
debug1: find_helper: using "c:\\Program Files\\OpenSSH\\ssh-sk-helper.exe" as helper
debug3: Creating process with CREATE_NO_WINDOW
debug3: spawning "c:\\Program Files\\OpenSSH\\ssh-sk-helper.exe" as subprocess
debug3: start_helper: started pid=19056
debug3: ssh_msg_send: type 5
debug3: ssh_msg_recv entering
debug1: client_converse: helper returned error -4
debug3: reap_helper: pid=19056
Key enrollment failed: invalid format
PS D:\> ssh -V
OpenSSH_for_Windows_8.9p1, LibreSSL 3.4.3
PS D:\>

Seems there are open issues (here and here) about this topic. Looks like there are way too many places where questions are asked, topics are discussed, ... for the Solo2 :-/

[d4g]

Well, the dev's decided not to use the regular issue tracking system for the solo2, which would mitigate this. I also don't know about any roadmap. Communication is difficult.

[gimiki]

Thanks, I have the same issue.
Seems that the issue is addressed in this pull request (Nitrokey repository): Nitrokey/nitrokey-3-firmware#46 (waiting for tests).

[stintel]

Still a problem on 2:20220822.0 :(

[darses]

Did you create a new SSH key? I got my Solo2 USB-C working under Fedora Linux 36 with the newest firmware version.

[PartTimeDataScientist]

On my side the problem shifted with the new firmware - generating resident sk keys seems to be possible but I didn't manage to extract the public key again which still defies the whole point of having resident keys...

Downloading latest release from https://github.com/solokeys/solo2/
Fetched firmware version 2:20220822.0 (2.964.0)
Warning: This is is major update and it could risk breaking any current credentials on your key.
Check latest release notes here to double check: https://github.com/solokeys/solo2/releases
If you haven't used your key for anything yet, you can ignore this.

✔ Continue? · yes
Continuing
Tap button on key to confirm, or replug to abort...
LPC55 Bootloader detected. The LED should be off.
Writing new firmware...
Done. Rebooting key. The LED should turn back on.

d:\>ssh-keygen -t ed25519-sk -Oresident -Oapplication=ssh:user.name
Generating public/private ed25519-sk key pair.
You may need to touch your authenticator to authorize key generation.
Enter file in which to save the key (C:\Users\user.name/.ssh/id_ed25519_sk): 
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in D:\id_ed25519_sk_TESTING2_DONT_USE
Your public key has been saved in D:\id_ed25519_sk_TESTING2_DONT_USE.pub
 [...]

d:\>ssh-keygen -K
Enter PIN for authenticator:
You may need to touch your authenticator to authorize key download.
Unable to load resident keys: invalid format```

[needs-coffee]

@PartTimeDataScientist same problem here - super secure resident keys tho 😆

[darses]

I guess there must be some other issue then. I do have to admit that ssh-add -K does not always recognize the security key, but after unplugging and plugging it in again, it works quite reliably.

[darses@localhost ~]$ ssh-add -D
All identities removed.
[darses@localhost ~]$ ssh-add -K -v
Enter PIN for authenticator: 
debug1: start_helper: starting /usr/libexec/openssh/ssh-sk-helper 
debug1: sshsk_load_resident: provider "internal", have-pin
debug1: sk_probe: 1 device(s) detected
debug1: sk_probe: selecting sk by touch
debug1: ssh_sk_load_resident_keys: trying /dev/hidraw10
debug1: read_rks: existing 2, remaining 98
debug1: read_rks: Device /dev/hidraw10 has resident keys for 2 RPs
debug1: read_rks: rp 0: name="Microsoft" id="login.microsoft.com" hashlen=32
debug1: read_rks: rp 1: name="(null)" id="ssh:" hashlen=32
debug1: read_rks: RP "ssh:" has 1 resident keys
debug1: read_rks: Device /dev/hidraw10 RP "ssh:" slot 0: type -8 flags 0x00 prot 0x02
debug1: process_load_resident: key 0 ED25519-SK ssh:
debug1: main: reply len 227
debug1: sshsk_load_resident: keys[0]: ED25519-SK ssh:
Resident identity added: ED25519-SK SHA256:VJTxdifTeYitNO5a1CRfniKPRyca+5V7JMDippYuV0s

I also tested this function by uploading the pubkey to Github, deleting the id_ed25519_sk.* files, reading the key information using ssh-add -Kand logging in to Github via SSH. This worked with the -O resident option, but gave problems when I tried adding the -O verify-required option.

EDIT: I also notice you specify the application name using -Oapplication=ssh:user.name. I did not do that, so perhaps you can try without that option.

[stintel]

Did you create a new SSH key? I got my Solo2 USB-C working under Fedora Linux 36 with the newest firmware version.

Updating to the new firmware wipes the key so all existing keys should be gone after that. Strangely enough, trying again today I no longer have the problem with ssh-add -K. This is great, can finally start retiring my Solo1 and Yubikeys.

Edit: maybe I misread/misunderstood, it invalidates credentials, maybe doesn't wipe them.

[nickray]

This should work (i.e. just verified, on Linux, openssh 9.0p1). The error messages can be confusing...

Steps:

1. set a PIN (chrome://settings/securityKeys or fido2-token -S <device>, getting device via fido2-token -L)
2. create a resident credential: ssh-keygen -t ed25519-sk -O resident (you can also add -O application=ssh:<anything you like> here, the entire "application" string will be treated as "relying party ID")
3. double check: fido2-token -L -r should list your key(s)
4. now ssh-add -K

[Nuc1eoN]

fido2-token -L -r does not work here. I am getting:

$ fido2-token -L -r
usage: fido2-token -C [-d] device
       fido2-token -Db [-k key_path] [-i cred_id -n rp_id] device
       fido2-token -Dei template_id device
       fido2-token -Du device
       fido2-token -Gb [-k key_path] [-i cred_id -n rp_id] blob_path device
       fido2-token -I [-cd] [-k rp_id -i cred_id]  device
       fido2-token -L [-bder] [-k rp_id] [device]
       fido2-token -R [-d] device
       fido2-token -S [-adefu] [-l pin_length] [-i template_id -n template_name] device
       fido2-token -Sb [-k key_path] [-i cred_id -n rp_id] blob_path device
       fido2-token -Sc -i cred_id -k user_id -n name -p display_name device
       fido2-token -Sm rp_id device
       fido2-token -V

So it does not look like a valid option sadly.

Anyways I continue with ssh-add -K and it promts me for my PIN, fine. No further output.

But then ssh-add -l shows:

The agent has no identities.

[wbcat]

Two steps

fido2-token -L

Will list your device. e.g. /dev/hidraw3

fido2-token -L -r /dev/hidraw3

will list the keys.

[wbcat]

For ssh-add -K the ssh-agent has to run. Try

eval `ssh-agent`

For convenience you can put this into your .bashrc or .profile

[PartTimeDataScientist]

The ssh-add -K doesn't work as well but finally pointed to the (stupid) solution. Found it in the Yubikey-Subreddit: On windows you need an elevated prompt and then everything is working fine. 😲 😖

D:\>ssh-keygen -K
Enter PIN for authenticator:
You may need to touch your authenticator to authorize key download.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Saved ED25519-SK key ssh:ùser.name to id_ed25519_sk_rk_user.name_48dea5b3ace108437d8ba5112c9d95f8f680c89d812be5f5f0a792a86f6cdeb7

D:\>

[sowbug]

No luck here. I did sudo here for fun, but the results are the same without it (I have udev set up properly).

$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.2 LTS"
$ fido2-token -L
/dev/hidraw0: vendor=0x1209, product=0xbeee (SoloKeys Solo 2 Security Key)
$ ssh -V
OpenSSH_8.2p1 Ubuntu-4ubuntu0.2, OpenSSL 1.1.1f  31 Mar 2020
$ solo2 app admin version
2:20220822.0
$ sudo ssh-keygen -v -t ed25519-sk -O resident -f /tmp/id_solo-1_sk
Generating public/private ed25519-sk key pair.
You may need to touch your authenticator to authorize key generation.
debug1: start_helper: starting /usr/lib/openssh/ssh-sk-helper 
debug1: sshsk_enroll: provider "internal", device "(null)", application "ssh:", 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
debug1: client_converse: helper returned error -43
Enter PIN for authenticator: 
debug1: start_helper: starting /usr/lib/openssh/ssh-sk-helper 
debug1: sshsk_enroll: provider "internal", device "(null)", application "ssh:", 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_MISSING_PARAMETER
debug1: sshsk_enroll: provider "internal" returned failure -1
debug1: ssh-sk-helper: Enrollment failed: invalid format
debug1: ssh-sk-helper: reply len 8
debug1: client_converse: helper returned error -4
Key enrollment failed: invalid format

[krogozinski]

If you have generated a key previously with an older solo2 firmware, try resetting the key first. I used the "Reset your security key" option in Chromium (chrome://settings/securityKeys). After this, I can add the key in Ubuntu 22.04 (OpenSSH 8.9p1) with "ssh-add -K" without issue.

[sowbug]

@krogozinski thanks, you gave me a clue. I'm on Ubuntu 20.04. Rather than upgrading the entire distro, I started with the leaf-node dependencies:

$ ls -l /usr/lib/x86_64-linux-gnu/*fido*
lrwxrwxrwx 1 root root     33 Mar 27  2020 /usr/lib/x86_64-linux-gnu/libfido2.so.1 -> libfido2.so.1.3.1
-rw-r--r-- 1 root root 145472 Mar 27  2020 /usr/lib/x86_64-linux-gnu/libfido2.so.1.3.1
$ git clone https://github.com/Yubico/libfido2
$ cd libfido2/
$ sudo apt install libcbor-dev
$ cmake -B build
$ make -C build
$ sudo make -C build install
$ sudo ln -sf /usr/local/lib/libfido2.so.1.12.0 libfido2.so.1
$ ls -l /usr/lib/x86_64-linux-gnu/*fido*
lrwxrwxrwx 1 root root     33 Sep 12 08:55 /usr/lib/x86_64-linux-gnu/libfido2.so.1 -> /usr/local/lib/libfido2.so.1.12.0
-rw-r--r-- 1 root root 145472 Mar 27  2020 /usr/lib/x86_64-linux-gnu/libfido2.so.1.3.1

Then I tried again, and everything now works as hoped.

TL;DR: Ubuntu 20.04's version of libfido2 is 1.3.1, which is older than 22.04's 1.12.0, and somewhere between those two versions, Solo resident support improved. (Note that I've been able to use Yubikey's resident feature since I first heard of it, so the bug might actually be something in Solo. Don't want to let them off the hook so easily. 😄 )

[needs-coffee]

The solution for me was to perform a reset with fido-token after updating even though the key was not reporting any stored credentials. Ed25519-sk works fine for me with resident keys now except for the verify-required flag as per issue trussed-dev/fido-authenticator#20

[gimiki]

I was able to generate ssh resident key but I have problems loading the key with ssh-add -K. I'm on Ubuntu 22.04 WSL, I will try tomorrow also on archlinux.

ssh version: OpenSSH_8.9p1 Ubuntu-3, OpenSSL 3.0.2 15 Mar 2022
solo2 firmware: 2:20220822.0
fido2-token: 1.10.0

I started with a reset fido2-token -R /dev/hidraw0, then setting pin with fido2-token -S /dev/hidraw0.

❯ ssh-keygen -v -t ed25519-sk -O resident -O application=ssh:94gimiki94
...
Your public key has been saved in /tmp/id_ed25519_sk.pub 
❯ fido2-token -L -r /dev/hidraw0
Enter PIN for /dev/hidraw0:
00: cEZjsrWoh0iava7JLYvGCpGVz5Joku8oXSF/xa/HxrY= ssh:94gimiki94
❯ fido2-token -I -c /dev/hidraw0
Enter PIN for /dev/hidraw0:
existing rk(s): 1
remaining rk(s): 99
❯ ssh-add -v -K
Enter PIN for authenticator:
debug1: start_helper: starting /usr/lib/openssh/ssh-sk-helper
debug1: sshsk_load_resident: provider "internal", have-pin
debug1: sk_probe: 1 device(s) detected
debug1: sk_probe: selecting sk by touch
debug1: ssh_sk_load_resident_keys: trying /dev/hidraw0
debug1: check_sk_options: option uv is unknown
debug1: read_rks: existing 1, remaining 99
debug1: read_rks: Device /dev/hidraw0 has resident keys for 1 RPs
debug1: read_rks: rp 0: name="(none)" id="ssh:94gimiki94" hashlen=32
debug1: read_rks: RP "ssh:94gimiki94" has 1 resident keys
debug1: read_rks: Device /dev/hidraw0 RP "ssh:94gimiki94" user "openssh" uidlen 32 slot 0: type -8 flags 0x00 prot 0x02                                 debug1: process_load_resident: key 0 ED25519-SK ssh:94gimiki94 uidlen 32
debug1: main: reply len 291
debug1: sshsk_load_resident: srks[0]: ED25519-SK ssh:94gimiki94 uidlen 32
Unable to add key ED25519-SK SHA256:64r1JU06dY5wnMK/aIbs3rt2ZqzdkoYAZalvsrk9Hwg

I tried also replugging the key, same result. Maybe doesn't work on old openssh version? @nickray tried with 9.0p1.
I don't know if it's due "check_sk_options: option uv is unknown" (like in trussed-dev/fido-authenticator#10) or because of WSL.

[needs-coffee]

openssh version 8.9 worked for me on ubuntu 22.04 - but the last word of your post probably identifies the problem - is this WSL 1 or 2?

[gimiki]

So maybe it's something with WSL or my setup. I have WSL2 on W10.
I had to recompile the kernel with the following options: CONFIG_USB_HIDDEV=y CONFIG_HIDRAW=y and I have the following udev rule in order to use the device without sudo: KERNEL=="hidraw*", SUBSYSTEM=="hidraw", MODE="0660", GROUP="plugdev"

[needs-coffee]

WSL2 is running in a modified hyper-v VM - its pretty fiddly with USB devices in general. you could try this https://learn.microsoft.com/en-us/windows/wsl/connect-usb but doesnt seem that convenient. Theres a note at the top about Windows 10 needing specific instructions you could try that.
are you able to run ssk-keygen -K on the windows 10 install in powershell (due to windows wierdness you need to run it as admin)

[jackinloadup]

I'm running into this issue on NixOS 23.05 running the following software versions:

• openssh-9.3p1
• libfido2-1.13.0
• solo2-cli-0.2.2

Using the latest Solo2 firmware

$ solo2 ls
Solo 2 57BD8C5F18005750B5C4BXXXXXXXXX (CTAP+PCSC, firmware 2:20220822.0, locked)

I started with a reset fido2-token -R /dev/hidraw9, then setting pin with fido2-token -S /dev/hidraw9.
Then generated a new key ssh-keygen -t ecdsa-sk -O resident also tried ssh-keygen -t ed25519-sk -O resident.

$ ssh-keygen -t ecdsa-sk -O resident
Generating public/private ecdsa-sk key pair.
You may need to touch your authenticator to authorize key generation.
Enter PIN for authenticator: 
You may need to touch your authenticator again to authorize key generation.
A resident key scoped to 'ssh:' with user id 'null' already exists.
Overwrite key in token (y/n)? y
You may need to touch your authenticator again to authorize key generation.
Enter file in which to save the key (/home/USER/.ssh/id_ecdsa_sk): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/USER/.ssh/id_ecdsa_sk
Your public key has been saved in /home/USER/.ssh/id_ecdsa_sk.pub
The key fingerprint is:
SHA256:7H8F1oNsXjpGqP4+g+oWjrRY7kO+mLJdWSO0YHLggiU lriutzel@reg
The key's randomart image is:
+-[ECDSA-SK 256]--+
|E .              |
|o+               |
|+.+ .      o o   |
|.+ o . .  . B +  |
|    o o S. = + . |
|    ++.o.   = .  |
|   Bo+ o.. . o   |
|...+* o o.o .    |
|.o+.o=o. o++     |
+----[SHA256]-----+

Then load the resident key

$ ssh-add -K -v
Enter PIN for authenticator: 
debug1: start_helper: starting /nix/store/960l5qaraqbm9mm5r002kgws7hi8vfhh-openssh-9.3p1/libexec/ssh-sk-helper 
debug1: sshsk_load_resident: provider "internal", have-pin
debug1: sk_probe: 2 device(s) detected
debug1: sk_probe: selecting sk by touch
debug1: sk_touch_poll: polling /dev/hidraw9
debug1: sk_touch_poll: polling pcsc://slot0
debug1: sk_touch_poll: polling /dev/hidraw9
debug1: ssh_sk_load_resident_keys: trying /dev/hidraw9
debug1: check_sk_options: option uv is unknown
debug1: read_rks: existing 1, remaining 99
debug1: read_rks: Device /dev/hidraw9 has resident keys for 1 RPs
debug1: read_rks: rp 0: name="(none)" id="ssh:" hashlen=32
debug1: read_rks: RP "ssh:" has 1 resident keys
debug1: read_rks: Device /dev/hidraw9 RP "ssh:" user "openssh" uidlen 32 slot 0: type -7 flags 0x00 prot 0x02
debug1: process_load_resident: key 0 ECDSA-SK ssh: uidlen 32
debug1: main: reply len 316
debug1: sshsk_load_resident: srks[0]: ECDSA-SK ssh: uidlen 32
Unable to add key ECDSA-SK SHA256:lIhLCp9lrSwvSoiurARFldv1RKW6niNHM2QzuzsfTAw

I tried as root with the same outcome. I also tried replugging and running ssh-add again.
I added the following udev rule but it didn't help as a user in the plugdev group or as the root user

KERNEL=="hidraw*", SUBSYSTEM=="hidraw", MODE="0660", GROUP="plugdev"

This is in addition to the "normal" udev rules I have for solo2

      # NXP LPC55 ROM bootloader (unmodified)
      SUBSYSTEM=="hidraw", ATTRS{idVendor}=="1fc9", ATTRS{idProduct}=="0021", TAG+="uaccess"
      # NXP LPC55 ROM bootloader (with Solo 2 VID:PID)
      SUBSYSTEM=="hidraw", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="b000", TAG+="uaccess"
      # Solo 2
      SUBSYSTEM=="tty", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="beee", TAG+="uaccess"
      # Solo 2
      SUBSYSTEM=="usb", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="beee", TAG+="uaccess"

I also tried to reset the key with chrome at chrome://settings/securityKeys and using chrome to set the pin. Then using ssh-keygen and ssh-add as before.

[hideaki-t]

It is working, so I didn't reset my solo2, but the steps above worked fine on my environment Arch WSL2 using usbipd.

mine had 2 RPs (MS account and ssh:<user-id> with ED25519-SK), and the step added another RP (ssh: withECDSA-SK )

$ ssh -V
OpenSSH_9.3p2, OpenSSL 3.1.1 30 May 2023

$ fido2-token -V
1.13.0

$ solo2 -V
solo2 0.2.2

$ solo2 ls
Solo 2 <snip> (CTAP+PCSC, firmware 2:20220822.0, locked)

note that libfido2 is not from Arch official repo, it does't support PCSC. so I recompiled it to see sk_touch_poll: polling pcsc://slot0, but I didn't see it. at least 2 devices were detected debug1: sk_probe: 2 device(s) detected - if I stop pscscd, only 1 detected.

[jackinloadup]

I figured out a solution. Maybe "the" solution.

The gnupg ssh agent that I'm running doesn't support using resident keys. I haven't dug into exactly why.
The openssh agent does work as expected.