solo1
solo1 copied to clipboard
solokeys
SSH support
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
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.
Well then we have to hope that it might be possible to support ed25519-sk in a firmware upgrade
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
Indeed only ecdsa will work currently.
Resident keys are supported. Will need to troubleshoot some to figure out what is happening.
Anything I can do to help troubleshooting, I have both secure and hacker
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?
# to update
unzip solo.hex.zip
solo program bootloader solo.hex
For some reason i'm having problems building the openssh package with the security key support @dlq84 @robinlandstrom what distribution are you running
@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.
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
@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.
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
@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 :)
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.
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.
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
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.
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?
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
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
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!
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-----
Does the 3.2.0 release mean these work now? And if so, how do I use it?
@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.
There is still no support for ed25519-sk.
@merlokk Does your recent work in solokeys/openpgp change this at all?
openpgp works with ed25519. but it not in the master now.
WearAuthn - different story. but it can be added after adding openpgp to master.
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,[email protected],ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected]>
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!
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)
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
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
