SSH support #374
Comments
|
I can confirm my Solokey USB-A Tap is working with openssh and key type 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 |
|
Can also confirm that Logging in with Somu attached by touching it Tying to login without the Somu attached results in Resident keys does not seem to be supported thou? Key generation looks okay. But retrieving the key from Somu fails with a |
|
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. |
|
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 |
|
yea for 8.2 its needed as it doesn't use libsk-libfido2.so anymore but the build in provider. |
|
@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 EDIT: just found out libfido2 now exist in the |
|
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 |
|
Flashed your new firmware, and did a Debug output when creating a resident key, sorry for the formatting.. Somu When trying to fetch the key 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: The command is defined as |
|
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? |
For the uninitiated, who is "they" referring to? And what are the ramifications? (i.e. Is neko right?)
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. |
|
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 |
Implement command 0x41 which is used by OpenSSH for reading RKs. It has the following subcommands: * CMD_CRED_METADATA - get number of saved/remaining RKs * CMD_RP_BEGIN/CMD_RP_NEXT - iterate over the saved RPs * CMD_RK_BEGIN/CMD_RK_NEXT - iterate over the RKs for a given RP This fixes issue solokeys#374
Implement command 0x41 which is used by OpenSSH for reading RKs. It has the following subcommands: * CMD_CRED_METADATA - get number of saved/remaining RKs * CMD_RP_BEGIN/CMD_RP_NEXT - iterate over the saved RPs * CMD_RK_BEGIN/CMD_RK_NEXT - iterate over the RKs for a given RP Fixes issue solokeys#374 and issue solokeys#314
Implement command 0x41 which is used by OpenSSH for reading RKs. It has the following subcommands: * CMD_CRED_METADATA - get number of saved/remaining RKs * CMD_RP_BEGIN/CMD_RP_NEXT - iterate over the saved RPs * CMD_RK_BEGIN/CMD_RK_NEXT - iterate over the RKs for a given RP Fixes issue solokeys#374 and issue solokeys#314
Implement command 0x41 which is used by OpenSSH for reading RKs. It has the following subcommands: * CMD_CRED_METADATA - get number of saved/remaining RKs * CMD_RP_BEGIN/CMD_RP_NEXT - iterate over the saved RPs * CMD_RK_BEGIN/CMD_RK_NEXT - iterate over the RKs for a given RP Fixes issue solokeys#374 and issue solokeys#314
|
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 |
Implement command 0x41 which is used by OpenSSH for reading RKs. It has the following subcommands: * CMD_CRED_METADATA - get number of saved/remaining RKs * CMD_RP_BEGIN/CMD_RP_NEXT - iterate over the saved RPs * CMD_RK_BEGIN/CMD_RK_NEXT - iterate over the RKs for a given RP Fixes issue solokeys#374 and issue solokeys#314
Implement command 0x41 which is used by OpenSSH for reading RKs. It has the following subcommands: * CMD_CRED_METADATA - get number of saved/remaining RKs * CMD_RP_BEGIN/CMD_RP_NEXT - iterate over the saved RPs * CMD_RK_BEGIN/CMD_RK_NEXT - iterate over the RKs for a given RP Fixes issue solokeys#374 and issue solokeys#314
Implement command 0x41 which is used by OpenSSH for reading RKs. It has the following subcommands: * CMD_CRED_METADATA - get number of saved/remaining RKs * CMD_RP_BEGIN/CMD_RP_NEXT - iterate over the saved RPs * CMD_RK_BEGIN/CMD_RK_NEXT - iterate over the RKs for a given RP Fixes issue solokeys#374 and issue solokeys#314
Implement command 0x41 which is used by OpenSSH for reading RKs. It has the following subcommands: * CMD_CRED_METADATA - get number of saved/remaining RKs * CMD_RP_BEGIN/CMD_RP_NEXT - iterate over the saved RPs * CMD_RK_BEGIN/CMD_RK_NEXT - iterate over the RKs for a given RP Fixes issue solokeys#374 and issue solokeys#314
|
Any progress on this front? |
|
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 It was also added to the My server, just returned this: 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: 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 max@computer ~ % ssh-add -K
Enter PIN for authenticator:
Unable to add key ECDSA-SK SHA256:XXXXXXXXXXXXXXX |
You can also use ed25519-sk, I just tested with Solokey and seems working now. |
|
Yes But that's sadly unrelated to my issue. |
|
Are you using a resident key? |
|
@enrikb Thanks for asking. Yes I'm using a I'm using
|
|
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. Then I made the key. (Don't know why it has to be 'resident' - if someone could elaborate?) after that the ssh-add worked Before making the key, the ssh-add failed like so 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? |
|
With v4.1.0, this can be closed, no? I think Ed25519 was the last outstanding issue. |
|
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. |
|
Yes, that's correct. |
|
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. |
|
I think the ssh tools will handle all keys having user ids starting with |
Could you please explain me which one is the PIN for authenticator? |
|
Hi,
Anyone else having this ? OS is archlinux up to date, and solo key is on firmware v4.1.2. |
|
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. |
|
I cannot reproduce the issue.
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 ( However, I can use both "private" keys (which actually only are key IDs) to login successfully after adding the matching public key to |
|
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. 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. 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. |
|
Again, I can't reproduce the issue. However, when I use the But all this seems more related to the OpenSSH binaries than to the Solo key. |
|
Is |
|
It looks like the The same seems to happen for I will try to find the reason. |
|
See #568 for the |
|
The |
|
@enrikb, thanks a lot for this meticulous and amazing investigation! And thanks for submitting the PR for How do you review the certificate file contents once the key is generated or re-downloaded from the device. I am having a hard time using |
|
@stefannegrea, openssh uses its own key file format. The best way to check the key flags at least that I have found, so far, is something like this: The flag values as found in openssh-portable's You can also see the flags being set or read back when calling |
|
@enrikb, thanks for the command, works really well for reviewing key contents. And thank you for investigating this issue. I see For Also, there might be some weirdness with |
|
After testing Another interesting discovery, if a key has |
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
The text was updated successfully, but these errors were encountered: