SSH support

[nekocentral]

Well ssh support might have gotten way easier as FIDO2/U2F just got officially supported in openssh 8.2 http://www.openssh.com/txt/release-8.2

[dlq84]

I can confirm my Solokey USB-A Tap is working with openssh and key type ecdsa-sk. I can not generate ed25519-sk though, I guess that key type is not supported by solokeys at all, though.

> ssh-keygen -t ed25519-sk -vvv                                                                  1 master!?
Generating public/private ed25519-sk key pair.
You may need to touch your authenticator to authorize key generation.
debug3: start_helper: started pid=71700
debug3: ssh_msg_send: type 5
debug3: ssh_msg_recv entering
debug1: start_helper: starting /usr/lib/ssh/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: ssh_sk_enroll: using device /dev/hidraw5
debug1: ssh_sk_enroll: fido_dev_make_cred: FIDO_ERR_UNSUPPORTED_ALGORITHM
debug1: sshsk_enroll: provider "internal" returned failure -2
debug1: ssh-sk-helper: Enrollment failed: requested feature not supported
debug1: ssh-sk-helper: reply len 8
debug3: ssh_msg_send: type 5
debug1: client_converse: helper returned error -59
debug3: reap_helper: pid=71700
Key enrollment failed: requested feature not supported

> ssh -V                                                                                                                     255
OpenSSH_8.2p1, OpenSSL 1.1.1d  10 Sep 2019

A heads up though; server needs to support *-sk in order to use it, so adoption will probably take some time.

[nekocentral]

Well then we have to hope that it might be possible to support ed25519-sk in a firmware upgrade

[robinlandstrom]

Can also confirm that ecdsa-sk is working with a Somu hacker 3.0.1

[zd@titan ~]$ solo key version
3.0.1 unlocked
[zd@titan ~]$ ssh-keygen -t ecdsa-sk -f ~/.ssh/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:
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/zd/.ssh/id_ecdsa_sk
Your public key has been saved in /home/zd/.ssh/id_ecdsa_sk.pub
The key fingerprint is:
SHA256:t6jVOY5H6BtgU81U232IbnUwKd7SvyR4n8VGzWWDtbI zd@titan
The key's randomart image is:
+-[ECDSA-SK 256]--+
|          ... =o |
|         +  .=.*+|
|        . o.o=++B|
|       .   .o.=.=|
|      + S.. +E + |
|     . o.+.= o .=|
|       .+.= . +.+|
|       o.+..   + |
|      . oo.      |
+----[SHA256]-----+
[zd@titan ~]$ cat ~/.ssh/id_ecdsa_sk.pub > ~/.ssh/authorized_keys

Logging in with Somu attached by touching it

[zd@titan ~]$ ssh localhost
Confirm user presence for key ECDSA-SK SHA256:t6jVOY5H6BtgU81U232IbnUwKd7SvyR4n8VGzWWDtbI
Last login: Sun Feb 16 11:45:36 2020 from ::1
[zd@titan ~]$

Tying to login without the Somu attached results in

[zd@titan ~]$ ssh localhost
Confirm user presence for key ECDSA-SK  SHA256:t6jVOY5H6BtgU81U232IbnUwKd7SvyR4n8VGzWWDtbI
sign_and_send_pubkey: signing failed for ECDSA-SK "/home/zd/.ssh/id_ecdsa_sk": invalid format

Resident keys does not seem to be supported thou?

Key generation looks okay.

[zd@titan ~]$ ssh-keygen -t ecdsa-sk -f ~/.ssh/id_ecdsa_sk -O resident -v
Generating public/private ecdsa-sk key pair.
You may need to touch your authenticator to authorize key generation.
debug1: start_helper: starting /usr/lib/ssh/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/ssh/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-helper: reply len 1076
/home/zd/.ssh/id_ecdsa_sk already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/zd/.ssh/id_ecdsa_sk
Your public key has been saved in /home/zd/.ssh/id_ecdsa_sk.pub
The key fingerprint is:
SHA256:69fPbnYMUO9FB6LVMFguIjcvAn2xzTCODVMr0ymhKj0 zd@titan
The key's randomart image is:
+-[ECDSA-SK 256]--+
|      +.=  o*o.. |
|     o O X.+ oo o|
|    o B % = .. o.|
| . . . B + ..   o|
|. E   . S .  . ..|
| . .   . o    . .|
|        .  .   o |
|       .  . ..o o|
|        ..   =+. |
+----[SHA256]-----+

But retrieving the key from Somu fails with a debug1: read_rks: device /dev/hidraw0 does not support resident keys

[zd@titan ~]$ ssh-add -K -v
Enter PIN for authenticator:
debug1: start_helper: starting /usr/lib/ssh/ssh-sk-helper
debug1: sshsk_load_resident: provider "internal", have-pin
debug1: ssh_sk_load_resident_keys: trying /dev/hidraw0
debug1: read_rks: device /dev/hidraw0 does not support resident keys
debug1: ssh-sk-helper: reply len 4

[conorpp]

Indeed only ecdsa will work currently.

Resident keys are supported. Will need to troubleshoot some to figure out what is happening.

[nekocentral]

Anything I can do to help troubleshooting, I have both secure and hacker

[conorpp]

I just built this hacker firmware with logs enabled, and will be visible over an emulated serial port (/dev/ttyACM or /dev/ttyUSB on Linux).

Can you program your hacker device with this, open serial port (e.g. picocom -b115200 /dev/ttyACM*), trigger the RK error, and post the logs?

solo.hex.zip

# to update
unzip solo.hex.zip
solo program bootloader solo.hex

[nekocentral]

For some reason i'm having problems building the openssh package with the security key support @dlq84 @robinlandstrom what distribution are you running

[dlq84]

@nekocentral I'm using Arch, I'm using the official PKGBUILD but added the --with-security-key-builtin flag to ./configure, not sure if that's strictly needed, though.

[nekocentral]

yea for 8.2 its needed as it doesn't use libsk-libfido2.so anymore but the build in provider. Going to liveboot an arch based OS and try there thanks

[dlq84]

@nekocentral It seems to me that it needs libfido2 even with that flag enabled. If I uninstall libfido2 (which I got from the AUR). I get

/usr/lib/ssh/ssh-sk-helper: error while loading shared libraries: libfido2.so.1: cannot open shared object file: No such file or directory

EDIT: just found out libfido2 now exist in the extra repo. So no AUR needed.

[nekocentral]

it does need libfido2, but in the past it also used an helper form what i can read, libsk-libfido2.so which is not required anymore as ssh-sk-helper has taken that role atleast if i understand https://bugs.archlinux.org/task/65513 properly

[robinlandstrom]

@conorpp

Flashed your new firmware, and did a solo key reset

Debug output when creating a resident key, sorry for the formatting..

$ ssh-keygen -t ecdsa-sk -f ~/.ssh/id_ecdsa_sk -O resident -v
Generating public/private ecdsa-sk key pair.
You may need to touch your authenticator to authorize key generation.
debug1: start_helper: starting /usr/lib/ssh/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-helper: reply len 1074
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/zd/.ssh/id_ecdsa_sk
Your public key has been saved in /home/zd/.ssh/id_ecdsa_sk.pub
The key fingerprint is:
SHA256:volfNq+TuB78e3eQRQuChuUAM3z2AwyNAFYpSe/DFSg zd@titan
The key's randomart image is:
+-[ECDSA-SK 256]--+
|.++o=**.o..      |
|.E.o o+Boo . .  .|
|  o. .o +.  . ...|
|  o .    o     ..|
|   +    S .    o |
|    .  o      o  |
|        +.+.   . |
|       ..Boo. . .|
|      .o*.+=.. . |
+----[SHA256]-----+

Somu

[CTAP] cbor input structure: 148 bytes
                                      [DUMP] cbor req: a5 01 58 20 b1 3d 5c 00 4c bb e5 78 43 a9 3c 9f 62 f1 39 9e 33 68 84 64 01 62 10 36 0e 90 24 9f 29 a1 26 3e 02 a1 62 69 64 64 73 73 68 3a 03 a3 62 69 64 58 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 64 6e 61 6d 65 67 6f 70 65 6e 73 73 68 6b 64 69 73 70 6c 61 79 4e 61 6d 65 67 6f 70 65 6e 73 73 68 04 81 a2 63 61 6c 67 26 64 74 79 70 65 6a 70 75 62 6c 69 63 2d 6b 65 79 07 a1 62 72 6b f5
                                                                                                                                                                 [MC]   b1 3d 5c 00 4c bb e5 78 43 a9 3c 9f 62 f1 39 9e 33 68 84 64 01 62 10 36 0e 90 24 9f 29 a1 26 3e
                                                                                               [MC]   ID: ssh:
                                                                                                              [MC]   name:
                                                                                                                           [MC] CTAP_user
                                                                                                                                         [MC]   ID: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                                                                           [MC] CTAP_pubKeyCredParams
                                                                                                     [MC]   cred_type: 0x01
                                                                                                                           [MC]   alg_type: -7
                                                                                                                                              [MC] CTAP_options
                                                                                                                                                               [GA] rk: 1
98 76 63 1b d4 a0 42 7f 57 73 0e c7 1c 9e 02 79
                                                [DEBUG] storing RK 0 @ 8039000
e3 06 10 e8 a1 62 11 59 60 fe 1e c2 23 e6 52 9c 9f 4b 6e 80 20 0d cb 5e 5c 32 1c 8a f1 e2 b1 bf
                                                                                                [DEBUG] MADE credId: 4f f8 b8 ef 14 92 25 8a c4 3b 2e d0 b4 42 7b 31 7b 6c c9 8f 1d 4f 56 8e 4e 68 61 cf 68 cb a9 63 33 d9 e3 06 10 e8 a1 62 11 59 60 fe 1e c2 23 e6 52 9c 9f 4b 6e 80 20 0d cb 5e 5c 32 1c 8a f1 e2 b1 bf 39 02 00 00
                                                                                                                                                              [MC] der sig [70]: 30 44 02 20 40 e4 cb 25 6f ff f7 39 66 01 fc 69 15 d8 75 86 cc 20 83 4b c4 80 65 57 4d f2 74 24 9e aa 24 05 02 20 69 31 65 d7 f1 09 28 f9 40 f3 bd f5 5d 92 1b 4c 31 30 74 0e d9 26 10 5c b8 0f 19 1a 82 eb bb 56
                                                 a3 01 66 70 61 63 6b 65 64 02 58 ca e3 06 10 e8 a1 62 11 59 60 fe 1e c2 23 e6 52 9c 9f 4b 6e 80 20 0d cb 5e 5c 32 1c 8a f1 e2 b1 bf 41 00 00 02 39 98 76 63 1b d4 a0 42 7f 57 73 0e c7 1c 9e 02 79 00 46 4f f8 b8 ef 14 92 25 8a c4 3b 2e d0 b4 42 7b 31 7b 6c c9 8f 1d 4f 56 8e 4e 68 61 cf 68 cb a9 63 33 d9 e3 06 10 e8 a1 62 11 59 60 fe 1e c2 23 e6 52 9c 9f 4b 6e 80 20 0d cb 5e 5c 32 1c 8a f1 e2 b1 bf 39 02 00 00 a5 01 02 03 26 20 01 21 58 20 a3 41 25 48 e6 57 63 57 1b 5f 6d 50 2b ce 96 23 0f d9 da df 2d fe e8 29 88 b2 60 76 1b 09 b0 6e 22 58 20 4c 54 ce d4 59 6b d6 5a fa 4b 19 30 40 36 61 d6 5e 9e 11 4d d2 44 72 8c e8 30 4c 4d 0d 4c f4 c8 03 a3 63 61 6c 67 26 63 73 69 67 58 46 30 44 02 20 40 e4 cb 25 6f ff f7 39 66 01 fc 69 15 d8 75 86 cc 20 83 4b c4 80 65 57 4d f2 74 24 9e aa 24 05 02 20 69 31 65 d7 f1 09 28 f9 40 f3 bd f5 5d 92 1b 4c 31 30 74 0e d9 26 10 5c b8 0f 19 1a 82 eb bb 56 63 78 35 63 81 59 02 ed 30 82 02 e9 30 82 02 8e a0 03 02 01 02 02 01 01 30 0a 06 08 2a 86 48 ce 3d 04 03 02 30 81 82 31 0b 30 09 06 055 04 06 13 02 55 53 31 11 30 0f 06 03 55 04 08 0c 08 4d 61 72 79 6c 61 6e 64 31 14 30 12 06 03 55 04 0a 0c 0b 53 4f 4c 4f 20 48 41 43 4b 45 52 31 10 30 0e 06 03 55 04 0b 0c 07 52 6f 6f 74 20 43 41 31 15 30 13 06 03 55 04 03 0c 0c 73 6f 6c 6f 6b 65 79 73 2e 63 6f 6d 31 21 30 1f 06 09 2a 86 48 86 f7 0d 01 09 01 16 12 68 65 6c 6c 6f 40 73 6f 6c 6f 6b 65 79 73 2e 63 6f 6d 30 20 17 0d 31 38 31 32 31 31 30 32 32 30 31 32 5a 18 0f 32 30 36 38 31 31 32 38 30 32 32 30 31 32 5a 30 81 94 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 11 30 0f 06 03 55 04 08 0c 08 4d 61 72 79 6c 61 6e 64 31 14 30 12 06 03 55 04 0a 0c 0b 53 4f 4c 4f 20 48 41 43 4b 45 52 31 22 30 20 06 03 55 04 0b 0c 19 41 75 74 68 65 6e 74 69 63 61 74 6f 72 20 41 74 74 65 73 74 61 74 69 6f 6e 31 15 30 13 06 03 55 04 03 0c 0c 73 6f 6c 6f 6b 65 79 73 2e 63 6f 6d 31 21 30 1f 06 09 2a 86 48 86 f7 0d 01 09 01 16 12 68 65 6c 6c 6f 40 73 6f 6c 6f 6b 65 79 73 2e 63 6f 6d 30 59 30 13 06 07 2a 86 48 ce 3d 02 01 06 08 2a 86 48 ce 3d 03 01 07 03 42 00 04 7d 78 f6 be ca 476 3b c7 5c e3 ac f4 27 12 c3 94 98 13 37 a6 41 0e 92 f6 9a 3b 15 47 8d b6 ce d9 d3 4f 39 13 ed 12 7b 81 14 3b e8 f9 4c 96 38 fe e3 d6 cb 1b 53 93 a2 74 f7 13 9a 0f 9d 5e a6 a3 81 de 30 81 db 30 1d 06 03 55 1d 0e 04 16 04 14 9a fb a2 21 09 23 b5 e4 7a 2a 1d 7a 6c 4e 03 89 92 a3 0e c2 30 81 a1 06 03 55 1d 23 04 81 99 30 81 96 a1 81 88 a4 81 85 30 81 82 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 11 30 0f 06 03 55 04 08 0c 08 4d 61 72 79 6c 61 6e 64 31 14 30 12 06 03 55 04 0a 0c 0b 53 4f 4c 4f 20 48 41 43 4b 45 52 31 10 30 0e 06 03 55 04 0b 0c 07 52 6f 6f 74 20 43 41 31 15 30 13 06 03 55 04 03 0c 0c 73 6f 6c 6f 6b 65 79 73 2e 63 6f 6d 31 21 30 1f 06 09 2a 86 48 86 f7 0d 01 09 01 16 12 68 65 6c 6c 6f 40 73 6f 6c 6f 6b 65 79 73 2e 63 6f 6d 82 09 00 eb d4 84 50 14 ab d1 57 30 09 06 03 55 1d 13 04 02 30 00 30 0b 06 03 55 1d 0f 04 04 03 02 04 f0 30 0a 06 08 2a 86 48 ce 3d 04 03 02 03 49 00 30 46 02 21 00 a1 7b 2a 1d 4e 42 a8 68 6d 65 61 1e f5 fe 6d c6 99 ae 7c 20 83 16 ba d6 e5 0f d7 0d 7e 05 da c9 02 21 00 92 49 f3 0

When trying to fetch the key

$ ssh-add -K -v
Enter PIN for authenticator:
debug1: start_helper: starting /usr/lib/ssh/ssh-sk-helper
debug1: sshsk_load_resident: provider "internal", have-pin
debug1: ssh_sk_load_resident_keys: trying /dev/hidraw0
debug1: read_rks: get metadata for /dev/hidraw0 failed: FIDO_ERR_NOT_SET
debug1: ssh_sk_load_resident_keys: read_rks failed for /dev/hidraw0
debug1: ssh-sk-helper: reply len 4

[CTAP] cbor input structure: 5 bytes
                                    [DUMP] cbor req: a2 01 01 02 02
                                                                    [CTAP] CTAP_CLIENT_PIN
                                                                                          [CP] CP map has 2 elements
                                                                                                                    [CP] CP_pinProtocol
                                                                                                                                       [CP] CP_subCommand
                                                                                                                                                         [CP] CP_cmdGetKeyAgreement
          a1 01 a5 01 02 03 38 18 20 01 21 58 20 55 60 74 1b e8 7d cd fe 12 d8 8f 30 01 3a 10 ef 93 5e 48 8c 89 cb 97 2a 54 f8 38 2d a8 3b 86 69 22 58 20 5a a7 d3 e4 0d 50 16 d2 75 9d 52 4e 65 ca 04 75 d6 0a 6c 30 43 84 c0 a1 7d 73 ea 81 4d 4d e1 b0
                                                                                 [CTAP] cbor input structure: 101 bytes
                                                                                                                       [DUMP] cbor req: a4 01 01 02 05 03 a5 01 02 03 26 20 01 21 58 20 d4 66 da 18 cb 63 7f 49 7b 7e e7 ff 75 51 66 84 18 78 8e 86 28 d3 ad 5a 11 15 65 16 46 39 ea fc 22 58 20 a2 5b ec d0 bc f4 9b 1f 4d bf e9 1b 9b 92 09 a5 fb c8 9a 84 e9 07 97 76 32 10 3f 84 6d ce 33 d3 06 50 1a 81 98 6d 2e a4 51 a9 27 0f 6b 13 2b 5f b7 d3
                                                                                                     [CP] CP_keyAgreement
                                                                                                                         [CP] CP_pinHashEnc

                                                                                                                                           [CTAP] cbor output structure: 0 bytes.  Return 0x35

If there is anything more I can help out with just ask :)

[rgerganov]

OpenSSH is using CTAP command 0x41 which is vendor specific to get the resident key. This is the log from Solo:

[HID] 
[HID] Recv packet
[HID]   CID: 00000006 
[HID]   cmd: 90
[HID]   length: 24
[HID] CTAPHID_CBOR
[CTAP] cbor input structure: 23 bytes
[DUMP] cbor req: a3 01 01 03 01 04 50 71 6b 30 0c d8 05 47 d5 01 51 fd dd 68 3c ab 80 
[ERR] ctap.c:1727: error, invalid cmd: 0x41
[CTAP] cbor output structure: 0 bytes.  Return 0x01
[TIME] CBOR writeback: 0 ms
[HID] 

The command is defined as CTAP_CBOR_CRED_MGMT_PRE in libfido2.

[nickray]

Oh, I see what's going on. There is a non-public "CTAP 2.1" (hence the "pre") spec that includes credential management. Interesting that they use this, the earlier demo version which "only" did U2F used normal/public commands. At least in principle this should work for resident keys (via CTAP 2.0 commands) too.

[nekocentral]

well that means we are screwed unless Solo becomes a member they cant get access to the pre specs, but because of the open-source nature of the firmware I don't think they can get it but I'm not sure

[Square252]

Is there an ETA for the ed25519 support? Or are there hw limits which prevent it's usage? Got some serious trust issues against ecdsa, since it's a nsa curve with rumors of intended broken rng math behind it.

[michaelblyons]

Oh, I see what's going on. There is a non-public "CTAP 2.1" (hence the "pre") spec that includes credential management. Interesting that they use this, the earlier demo version which "only" did U2F used normal/public commands. At least in principle this should work for resident keys (via CTAP 2.0 commands) too.

For the uninitiated, who is "they" referring to? And what are the ramifications? (i.e. Is neko right?)

Is there an ETA for the ed25519 support? Or are there hw limits which prevent it's usage? Got some serious trust issues against ecdsa, since it's a nsa curve with rumors of intended broken rng math behind it.

I don't imagine it's a hardware thing. Else https://github.com/solokeys/openpgp/issues/3 would have been closed, no?

[nekocentral]

Oh, I see what's going on. There is a non-public "CTAP 2.1" (hence the "pre") spec that includes credential management. Interesting that they use this, the earlier demo version which "only" did U2F used normal/public commands. At least in principle this should work for resident keys (via CTAP 2.0 commands) too.

For the uninitiated, who is "they" referring to? And what are the ramifications? (i.e. Is neko right?)

Is there an ETA for the ed25519 support? Or are there hw limits which prevent it's usage? Got some serious trust issues against ecdsa, since it's a nsa curve with rumors of intended broken rng math behind it.

I don't imagine it's a hardware thing. Else solokeys/openpgp#3 would have been closed, no?

They refer to the openssh devs/people that submitted code for the physical key part. But what I find dirty in this is that only the yubikey from yubico works with openssh atm which I think is because that they are part of the editors/board of the Fido Alliance

[nekocentral]

Interesting, it seems that openssh is already working with the trezor tokens https://blog.trezor.io/openssh-with-fido2-and-trezor-e565c2277, looking at their firmware tho incant really find the code for it, or I might just be blind

[rgerganov]

I have implemented the commands which are used by OpenSSH for operating with resident keys. You can test my PR#392 with Solo Hacker. Any feedback is welcome!

[rgerganov]

Another way of testing the credential management functionality is with the fido2-token tool from libfido2:

$ fido2-token -L /dev/hidraw6   
/dev/hidraw6: vendor=0x0483, product=0xa2ca (SoloKeys Solo 3.1.2-2-g423c580)
$ fido2-token -I -c /dev/hidraw6
Enter PIN for /dev/hidraw6: 
existing rk(s): 2
possible rk(s): 48
$ fido2-token -L -r /dev/hidraw6
Enter PIN for /dev/hidraw6: 
00: 4wYQ6KFiEVlg/h7CI+ZSnJ9LboAgDcteXDIcivHisb8= ssh:
01: rrA4hJfIw9N1wVfucgaYrHh4vocK2PGqmTcvrF20W1Q= 
$ fido2-token -L -k 'ssh:' /dev/hidraw6 
Enter PIN for /dev/hidraw6: 
00: F815ll21Ti43JcQcquNQZ1pGsF0DyK5At7m0KO44F3Z5ruMGEOihYhFZYP4ewiPmUpyfS26AIA3LXlwyHIrx4rG/6QEAAA== openssh (YWxpY2UAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=) es256
$ fido2-token -I -k 'ssh:' -i F815ll21Ti43JcQcquNQZ1pGsF0DyK5At7m0KO44F3Z5ruMGEOihYhFZYP4ewiPmUpyfS26AIA3LXlwyHIrx4rG/6QEAAA== /dev/hidraw6
Enter PIN for /dev/hidraw6: 
F815ll21Ti43JcQcquNQZ1pGsF0DyK5At7m0KO44F3Z5ruMGEOihYhFZYP4ewiPmUpyfS26AIA3LXlwyHIrx4rG/6QEAAA==
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEqqZzzdAS7aRmwMPixCfpIQF8BeP0
wKVwXuF1yqMkrxB5xVbMFGUbd6DEGi8f6AN/V8xsMNfX0JPC5ThjtqkujA==
-----END PUBLIC KEY-----

[michaelblyons]

Does the 3.2.0 release mean these work now? And if so, how do I use it?

[dlq84]

@michaelblyons Depends on what you're asking for specifically. ssh with ecdsa-sk, both normal keys and resident keys should now work.

There is still no support for ed25519-sk.

[michaelblyons]

There is still no support for ed25519-sk.

@merlokk Does your recent work in solokeys/openpgp change this at all?

[merlokk]

openpgp works with ed25519. but it not in the master now.

WearAuthn - different story. but it can be added after adding openpgp to master.

[mielouk]

Any progress on this front?

[max-wittig]

I'm a bit confused. Maybe somebody can clarify, that would be helpful.

Should ssh work or not?

I've generated the ssh key and it worked as expected with ssh-keygen -t ecdsa-sk.

It was also added to the ~/.ssh/authorized_keys, like all the other keys I got. To be sure, I've also restarted sshd.

My server, just returned this:

ssh -v -i /Users/max/.ssh/id_ecdsa_sk -A max@server

debug1: Will attempt key: /Users/max/.ssh/id_ecdsa_sk ECDSA-SK SHA256:xxx explicit authenticator
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com>
max@server: Permission denied (publickey).

On the server side, I just get:

ubuntu-20-04 sshd[25219]: Connection closed by authenticating user max <ip> port 27199 [preauth]

Server OpenSSH version: OpenSSH_8.2p1 Ubuntu-4ubuntu0.1, OpenSSL 1.1.1f 31 Mar 2020 Client OpenSSH version: OpenSSH_8.4p1, OpenSSL 1.1.1i 8 Dec 2020

Thanks for any help!

[max-wittig]

Sorry, I've just noticed that I copy pasted some spaces into the public key. Now it's working! 😄

ssh -i /Users/max/.ssh/id_ecdsa_sk max@server
Enter passphrase for key '/Users/max/.ssh/id_ecdsa_sk':
Confirm user presence for key ECDSA-SK SHA256:XXXXXXX
Welcome to Ubuntu 20.04.1 LTS (GNU/Linux 5.4.0-62-generic x86_64)

[max-wittig]

Just one more question. Should ssh-add also work with ssh-add -K?

max@computer ~ % ssh-add -K
Enter PIN for authenticator: 
Unable to add key ECDSA-SK SHA256:XXXXXXXXXXXXXXX

[gimiki]

Sorry, I've just noticed that I copy pasted some spaces into the public key. Now it's working!

ssh -i /Users/max/.ssh/id_ecdsa_sk max@server
Enter passphrase for key '/Users/max/.ssh/id_ecdsa_sk':
Confirm user presence for key ECDSA-SK SHA256:XXXXXXX
Welcome to Ubuntu 20.04.1 LTS (GNU/Linux 5.4.0-62-generic x86_64)

You can also use ed25519-sk, I just tested with Solokey and seems working now. For example (also with resident key):

ssh-keygen -t ed25519-sk -O resident

% solo key version
4.1.0 locked

[max-wittig]

Yes ed25519 support was added just in this update that came out a few days ago.

But that's sadly unrelated to my issue. ssh-add is still not working.

[enrikb]

ssh-add -K works pretty well for me:

$ ssh-add -K
Enter PIN for authenticator: 
Resident identity added: ED25519-SK SHA256:6wQr4MFDVLSOdgXG+XmYEKxLiSG/+vi4OhgWKXqx9zs
$ ssh-add -l
256 SHA256:6wQr4MFDVLSOdgXG+XmYEKxLiSG/+vi4OhgWKXqx9zs  (ED25519-SK)

Are you using a resident key?

[max-wittig]

@enrikb Thanks for asking. Yes I'm using a resident key, but also with the key only on the local machine, this didn't work.

I'm using brew install openssh on macOS. What are you using to make it work?

ssh-add -K output:

max@computer /tmp % ssh-add -v -K
Enter PIN for authenticator: 
debug1: start_helper: starting /usr/local/Cellar/openssh/8.4p1_2/libexec/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 IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/XHC1@14/XHC1@14000000/HS07@14200000/Solo 4.1.0@14200000/Solo 4.1.0@0/AppleUserUSBHostHIDDevice
debug1: read_rks: existing 1, remaining 49
debug1: read_rks: Device IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/XHC1@14/XHC1@14000000/HS07@14200000/Solo 4.1.0@14200000/Solo 4.1.0@0/AppleUserUSBHostHIDDevice has resident keys for 1 RPs
debug1: read_rks: rp 0: name="openssh" id="ssh:" hashlen=32
debug1: read_rks: RP "ssh:" has 1 resident keys
debug1: read_rks: Device IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/XHC1@14/XHC1@14000000/HS07@14200000/Solo 4.1.0@14200000/Solo 4.1.0@0/AppleUserUSBHostHIDDevice RP "ssh:" slot 0: type -8 flag
s 0x00 prot 0x01
debug1: process_load_resident: key 0 ED25519-SK ssh:
debug1: ssh-sk-helper: reply len 165
debug1: sshsk_load_resident: keys[0]: ED25519-SK ssh:
Unable to add key ED25519-SK SHA256:XXXXXXXXXXX

[mielouk]

Great work! Both work for me!

The update of the key didn't work the first time. The key blinked red/orange but the updater stopped. Rerun of the updater fixed the problem.

▶ solo key version
4.0.0 locked

~
▶ solo key update
Wrote temporary copy of firmware-4.1.0.json to /tmp/tmp_xa4in1r.json
sha256sums coincide: lalala (edited)
Switching into bootloader mode...
error:
problem flashing firmware!
no Solo found

~                                                                                                                                                                                                                                            ⍉
▶ solo key update
Not using FIDO2 interface.
Wrote temporary copy of firmware-4.1.0.json to /tmp/tmpov4525jh.json
sha256sums coincide: lalala (edited)
using signature version >2.5.3
erasing firmware...
updated firmware 100%
time: 9.46 s
bootloader is verifying signature...
...pass!

Congratulations, your key was updated to the latest firmware version: 4.1.0

Then I made the key. (Don't know why it has to be 'resident' - if someone could elaborate?)

▶ ssh-keygen -t ed25519-sk -O resident
Generating public/private ed25519-sk key pair.
You may need to touch your authenticator to authorize key generation.
Enter PIN for authenticator:
Enter file in which to save the key (/home/edit/.ssh/id_ed25519_sk):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/edit/.ssh/id_ed25519_sk
Your public key has been saved in /home/edit/.ssh/id_ed25519_sk.pub
The key fingerprint is:
SHA256: lala (edited) edit@edit

after that the ssh-add worked

▶ ssh-add -v -K
Enter PIN for authenticator:
debug1: start_helper: starting /usr/lib/ssh/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/hidraw5
debug1: read_rks: existing 1, remaining 49
debug1: read_rks: Device /dev/hidraw5 has resident keys for 1 RPs
debug1: read_rks: rp 0: name="openssh" id="ssh:" hashlen=32
debug1: read_rks: RP "ssh:" has 1 resident keys
debug1: read_rks: Device /dev/hidraw5 RP "ssh:" slot 0: type -8 flags 0x00 prot 0x01
debug1: process_load_resident: key 0 ED25519-SK ssh:
debug1: ssh-sk-helper: reply len 165
debug1: sshsk_load_resident: keys[0]: ED25519-SK ssh:
Resident identity added: ED25519-SK SHA256:lala-edited

Before making the key, the ssh-add failed like so

Enter PIN for authenticator:
debug1: start_helper: starting /usr/lib/ssh/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/hidraw5
debug1: read_rks: existing 0, remaining 50
debug1: read_rks: get RPs for /dev/hidraw5 failed: FIDO_ERR_RX_NOT_CBOR
debug1: ssh_sk_load_resident_keys: read_rks failed for /dev/hidraw5
Provider "internal" returned failure -1
debug1: ssh-sk-helper:  sshsk_load_resident failed: invalid format
debug1: ssh-sk-helper: reply len 8
debug1: client_converse: helper returned error -4
Unable to load resident keys: invalid format

EDIT: If I understand this correctly, there can be up to 50 generated keys be stored on the solo key itself. If I add them via ssh-add -K, how do I choose which key to import? Or does it import all of them?

[michaelblyons]

With v4.1.0, this can be closed, no? I think Ed25519 was the last outstanding issue.

[mielouk]

The resident keys are a very nice feature I've to say! The keys get only imported in the ssh-agent but don't get copied into the local .ssh folder. After import SSH says that the key is available in the .ssh folder, but the key doesn't really reside on the disk. Very nice indeed!

debug1: Will attempt key:  ED25519-SK SHA256:lala-edit authenticator agent
debug1: Will attempt key: /home/user/.ssh/id_ed25519_sk  explicit
debug1: Will attempt key: /home/user/.ssh/id_ed ED25519 SHA256:lala-edit

[enrikb]

Yes, that's correct. Optionally, if you want to, you can store the keys on disk by using ssh-keygen -K (works on every machine, not only the one that assisted in generating the key). I often do this to be able to name a key in .ssh/config. The pubkey-file is sufficient for that, so you can even delete the private key file after exporting a resident key.

[mielouk]

Very good to know!

What I haven't tested yet is the presence of several resident keys on the solo. Will ssh-add -K and ssh-keygen -K import all of them (up to 50?) or is there a way to manage what keys get imported? Also, how would I delete/manage resident keys on Solo, e.g. if all 50 were to be used and I would want to get rid of an old one.

[enrikb]

I think the ssh tools will handle all keys having user ids starting with ssh: at once, but I haven't tested this extensively, so far. For managing single resident keys (like deleting a specific one), you might want to check fido2-token from libfido2.

[michaelblyons]

https://github.com/solokeys/solo/blob/a87e1c6d15ef90b3ff7071abb86d3ef0d035b7fd/targets/stm32l432/src/device.c#L790-L800

[Romerolweb]

Can also confirm that ecdsa-sk is working with a Somu hacker 3.0.1

[zd@titan ~]$ solo key version
3.0.1 unlocked
[zd@titan ~]$ ssh-keygen -t ecdsa-sk -f ~/.ssh/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:
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/zd/.ssh/id_ecdsa_sk
Your public key has been saved in /home/zd/.ssh/id_ecdsa_sk.pub
The key fingerprint is:
SHA256:t6jVOY5H6BtgU81U232IbnUwKd7SvyR4n8VGzWWDtbI zd@titan
The key's randomart image is:
+-[ECDSA-SK 256]--+
|          ... =o |
|         +  .=.*+|
|        . o.o=++B|
|       .   .o.=.=|
|      + S.. +E + |
|     . o.+.= o .=|
|       .+.= . +.+|
|       o.+..   + |
|      . oo.      |
+----[SHA256]-----+
[zd@titan ~]$ cat ~/.ssh/id_ecdsa_sk.pub > ~/.ssh/authorized_keys

Logging in with Somu attached by touching it

[zd@titan ~]$ ssh localhost
Confirm user presence for key ECDSA-SK SHA256:t6jVOY5H6BtgU81U232IbnUwKd7SvyR4n8VGzWWDtbI
Last login: Sun Feb 16 11:45:36 2020 from ::1
[zd@titan ~]$

Tying to login without the Somu attached results in

[zd@titan ~]$ ssh localhost
Confirm user presence for key ECDSA-SK  SHA256:t6jVOY5H6BtgU81U232IbnUwKd7SvyR4n8VGzWWDtbI
sign_and_send_pubkey: signing failed for ECDSA-SK "/home/zd/.ssh/id_ecdsa_sk": invalid format

Resident keys does not seem to be supported thou?

Key generation looks okay.

[zd@titan ~]$ ssh-keygen -t ecdsa-sk -f ~/.ssh/id_ecdsa_sk -O resident -v
Generating public/private ecdsa-sk key pair.
You may need to touch your authenticator to authorize key generation.
debug1: start_helper: starting /usr/lib/ssh/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/ssh/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-helper: reply len 1076
/home/zd/.ssh/id_ecdsa_sk already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/zd/.ssh/id_ecdsa_sk
Your public key has been saved in /home/zd/.ssh/id_ecdsa_sk.pub
The key fingerprint is:
SHA256:69fPbnYMUO9FB6LVMFguIjcvAn2xzTCODVMr0ymhKj0 zd@titan
The key's randomart image is:
+-[ECDSA-SK 256]--+
|      +.=  o*o.. |
|     o O X.+ oo o|
|    o B % = .. o.|
| . . . B + ..   o|
|. E   . S .  . ..|
| . .   . o    . .|
|        .  .   o |
|       .  . ..o o|
|        ..   =+. |
+----[SHA256]-----+

But retrieving the key from Somu fails with a debug1: read_rks: device /dev/hidraw0 does not support resident keys

[zd@titan ~]$ ssh-add -K -v
Enter PIN for authenticator:
debug1: start_helper: starting /usr/lib/ssh/ssh-sk-helper
debug1: sshsk_load_resident: provider "internal", have-pin
debug1: ssh_sk_load_resident_keys: trying /dev/hidraw0
debug1: read_rks: device /dev/hidraw0 does not support resident keys
debug1: ssh-sk-helper: reply len 4

Could you please explain me which one is the PIN for authenticator?

[xogium]

Hi, I just got my new shiny solo key from leetronics today and I've been trying to set it up for resident keys with openssh, and I think I might have hit a bug. I'm not sure if it is from openssh, or from solo, that said.

1. Generate a key pair like so

ssh-keygen -t ed25519-sk -O resident

2. Add the pub key generated to your authorized_keys file on the remote host.
3. Log in with it to confrim it works.
4. Rename both the files so you back them up, or delete them, at this point it doesn't matter, you'll see why.
5. run ssh-keygen -K to get the key extracted from your solo again. Notice they were name id_ed25519_sk_rk and same for .pub, no idea why.
6. But alright then, try to give them their correct name, and take away the _rk portion, and try to log in. Ssh will then complain about invalid format.
7. If you use cmp on your backed up private ssh key, in case you backed it up, and compare with the one you just extracted, they are different. I don't suppose they should be, but, there you have it.
8. Even if you grab the backups you've made and put them in place of the extracted files, ssh will forever complain about invalid format and refuse to work.

Anyone else having this ?

OS is archlinux up to date, and solo key is on firmware v4.1.2.

[xogium]

After some more investigation it appears a reboot is required to make it work again.

Or I assume it is like a reboot since I unplugged and replugged it. If you do this then things go back to normal, at least with the files ssh-keygen first generated. If you then extract the key from your device again, everything works. I'm not quite sure what's been going on here, but I've managed to reproduce this twice.

[enrikb]

I cannot reproduce the issue.

• generated a new resident SSH key using the command you gave, saving it to id_ed25519_test_new_sk{.pub}
• export it again from the Solo key using ssh-keygen -K, saving it to the default filename id_ed25519_sk_rk{.pub}

The public keys are identical, just the comment differs. The private keys seem to differ, most probably because the comment also differs. Generating the public key from both private key files (ssh-keygen -e -f ...) returns the same identical public key.

However, I can use both "private" keys (which actually only are key IDs) to login successfully after adding the matching public key to authorized_keys. For this test, I explicitly passed the key files to ssh using -i .... (Ubuntu 21.04, firmware v4.1.2, OpenSSH_8.4p1 Ubuntu-5ubuntu1, OpenSSL 1.1.1j 16 Feb 2021)

[xogium]

This is indeed very strange. Since yesterday, I've not been able to reproduce this issue anymore.

That being said it seems ssh is a bit on shaky ground sometimes with this kind of keys.

Sometimes when you try to log in with a key that was set up with the -O verify-required option, it will ask you for PIN as it should but with a surprise package: an extremely short timeout almost impossible to get right to press the button afterwards.

Enter PIN for ED25519-SK key sigma:
Confirm user presence for key ED25519-SK SHA256:59UvKRhAGFnBrs1lXFVtICk7qnk5xdoJC86QGYYZwfo
sign_and_send_pubkey: signing failed for ED25519-SK "sigma": invalid format
xogium@fd68:afab:a08b::1: Permission denied (publickey)

The only solution to this appears to be to simultaneously press enter to send PIN and button on solo, and even then you have a really short window. I'm not even quite sure what can cause this, tbh.

There is also the ssh-keygen part. When you first generate the keys, it is okay and even asks you where to save them and what file name to use. But when running with -K to retrieve keys from device it names them on its own, and you don't have a say in it. They also don't have exactly the same name as the original, and have a _rk sufix for 'resident key'... Thanks, I knew that already, buddy.

Point is you then have to rename them if you're like me and use ssh config file, which is a bit bothersome.

As for whoever said they hadn't tried with multiple resident keys, well I just tried ;) it exports all of them, provided they were generated with a good application name when first created e.g: passing -O application:github to ssh-keygen. It doesn't let you pick which keys to grab, from what I could see, but it at least extracts all of them.

[enrikb]

Again, I can't reproduce the issue.

However, when I use the -O verify-required key, I have to disable the ssh-agent, like

SSH_AUTH_SOCK= ssh -i ... localhost

But all this seems more related to the OpenSSH binaries than to the Solo key.

[stefannegrea]

Is no-touch-required option supported for resident ed25519-sk keys?

[enrikb]

It looks like the no-touch-required flag gets lost between ssh-keygen for generating the key and ssh-keygen -K when reading the resident key back. This seems to be the case for both ecdsa-sk and ed25519-sk.

The same seems to happen for verify-required, but only for ed25519-sk.

I will try to find the reason.

[enrikb]

See #568 for the verify-required part.

[enrikb]

The no-touch-required flag is an ssh 'private' flag stored in the key file. When downloading resident keys using ssh-keygen -K or ssh-add -K, this flag will not be restored (technically, the flag SSH_SK_USER_PRESENCE_REQD is always set), AFAICS. So, no-touch-required is supported for both resident and non-resident openssh ed25519-sk keys. However, with the current openssh default FIDO2 USB backend, it does not seem to be possible to reconstruct an ed25519-sk openssh key from a resident key having no-touch-required. The same should hold for ecdsa-sk keys.