Win32-OpenSSH icon indicating copy to clipboard operation
Win32-OpenSSH copied to clipboard

ssh-add -K fails.

Open bagajjal opened this issue 3 years ago • 10 comments
trafficstars

Problem statement Win32-OpenSSH introduced FIDO support in V8.9.0.0. ssh-add -K is supposed to "Load resident keys from a FIDO authenticator".

Win32-OpenSSH currently doesn't support this option.

Work around Download the keys using ssh-keygen.exe -K. ssh-keygen -K requires direct communication with the FIDO token, so it needs to be issued from an elevated prompt.

bagajjal avatar Mar 21 '22 18:03 bagajjal

Because of this: https://github.com/PowerShell/openssh-portable/blob/latestw_all/ssh-add.c#L946 vs https://github.com/PowerShell/openssh-portable/blob/latestw_all/ssh-keygen.c#L3521 one has to either use -S internal or set SSH_SK_PROVIDER to internal

> ssh-add -K -S internal  
Enter PIN for authenticator:  
Unable to add key ED25519-SK SHA256:lXEl.....

But looks like there are more issues down the road.

bugficks avatar Jul 25 '22 01:07 bugficks

adding SSH2_AGENTC_ADD_ID_CONSTRAINED to: https://github.com/PowerShell/openssh-portable/blob/latestw_all/contrib/win32/win32compat/ssh-agent/connection.c#L145

	case SSH2_AGENTC_ADD_ID_CONSTRAINED:
	case SSH2_AGENTC_ADD_IDENTITY:
		r =  process_add_identity(request, response, con);
> ssh-add -K -S internal
Enter PIN for authenticator:
Resident identity added: ED25519-SK SHA256:lXEl.....
Resident identity added: ED25519-SK SHA256:CcxR.....
Resident identity added: ED25519-SK SHA256:xKXd.....
Resident identity added: ED25519-SK SHA256:GmY.....

> ssh-add -L
[email protected] AAAAGnNrLXNzaC1lZDI....
[email protected] AAAAGnNrLXNzaC1lZDI....
[email protected] AAAAGnNrLXNzaC1lZDI....
[email protected] AAAAGnNrLXNzaC1lZDI....

😄

bugficks avatar Jul 25 '22 02:07 bugficks

using Win10 with OpenSSH_for_Windows_9.1p1, LibreSSL 3.6.1 and loading resident keys from secure-key :

PS C:\Users\esa> ssh-add -K -S internal -vvv
Enter PIN for authenticator:
debug1: find_helper: using "C:\\Program Files (x86)\\OpenSSH\\ssh-sk-helper.exe" as helper
debug3: Creating process with CREATE_NO_WINDOW
debug3: spawning "C:\\Program Files (x86)\\OpenSSH\\ssh-sk-helper.exe" as subprocess
debug3: start_helper: started pid=2900
debug3: ssh_msg_send: type 5
debug3: ssh_msg_recv entering
debug1: client_converse: helper returned error -4
debug3: reap_helper: pid=2900
Unable to load resident keys: invalid format

any idea what caused this invalid format ?? Key type used is " -t ecdsa-sk" and keygen does not raise any errors.

netmiller avatar Jan 25 '23 11:01 netmiller

And this is same process with another/different secure-key (Yubikey BIO) :

PS$ ssh-keygen.exe -t ecdsa-sk -f .\fido2bio -O "resident"
Generating public/private ecdsa-sk key pair.
You may need to touch your authenticator 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 to authorize key generation.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in .\fido2bio
Your public key has been saved in .\fido2bio.pub
The key fingerprint is:
SHA256:yFC8h6U2+bybZJZEziMwj/HRCTO4Lg3l0Q06QrmH/5c esa@ESALAITILA0979
The key's randomart image is:
+-[ECDSA-SK 256]--+
|  .. +*o         |
| .. +oo=o.       |
|  .=Bo.*+        |
|  +.+@B*.        |
|   *..*=S        |
|  . +  ooo       |
|   . .  =o       |
|      .+E.       |
|       .o.       |
+----[SHA256]-----+

Seems to be ok. Loading with ssh-add :

PS$  ssh-add -K -S internal -vvv
Enter PIN for authenticator:
debug1: find_helper: using "C:\\Program Files (x86)\\OpenSSH\\ssh-sk-helper.exe" as helper
debug3: Creating process with CREATE_NO_WINDOW
debug3: spawning "C:\\Program Files (x86)\\OpenSSH\\ssh-sk-helper.exe" as subprocess
debug3: start_helper: started pid=8848
debug3: ssh_msg_send: type 5
debug3: ssh_msg_recv entering
debug3: reap_helper: pid=8848
debug1: sshsk_load_resident: srks[0]: ECDSA-SK ssh: uidlen 32
debug1: sshsk_load_resident: srks[1]: ECDSA-SK ssh: uidlen 32
debug1: sshsk_load_resident: srks[2]: ECDSA-SK ssh: uidlen 32
debug1: sshsk_load_resident: srks[3]: ECDSA-SK ssh:* uidlen 32
debug1: sshsk_load_resident: srks[4]: ECDSA-SK ssh:* uidlen 32
debug1: sshsk_load_resident: srks[5]: ECDSA-SK ssh:* uidlen 32
debug1: sshsk_load_resident: srks[6]: ECDSA-SK ssh:* uidlen 32
debug1: sshsk_load_resident: srks[7]: ECDSA-SK ssh:* uidlen 32
debug1: sshsk_load_resident: srks[8]: ECDSA-SK ssh:* uidlen 32
debug3: ReadFileEx() ERROR:109, io:036C7F60
debug3: read - no more data, io:036C7F60
Unable to add key ECDSA-SK SHA256:yFC8h6U2+bybZJZEziMwj/HRCTO4Lg3l0Q06QrmH/5c
debug3: write ERROR from cb(2):232, io:036C7F60
Unable to add key ECDSA-SK SHA256:SAtvgDtuy6bocAr5+XvEsR6B1FF9cn1/6QCfTzLCEZM
debug3: write ERROR from cb(2):232, io:036C7F60
Unable to add key ECDSA-SK SHA256:tguvgRImgOh82uRiZVsjYDJNqEjA/7cm1IjjfZZySfQ
debug3: write ERROR from cb(2):232, io:036C7F60
Unable to add key ECDSA-SK SHA256:A70TYdQ907QGkl//wPdxsPxFGn+AnW7up3QUHYoEoq8
debug3: write ERROR from cb(2):232, io:036C7F60
Unable to add key ECDSA-SK SHA256:TS5+wl2Iz6+DNSLn133oSE5Rw98Y+U+jzQyILV23GN8
debug3: write ERROR from cb(2):232, io:036C7F60
Unable to add key ECDSA-SK SHA256:NzqAko+ea3aw+Kq9Mbq9J0A2Dscfqaoz5bVhwIyr6jw
debug3: write ERROR from cb(2):232, io:036C7F60
Unable to add key ECDSA-SK SHA256:yV7rUA/nj6YDn7TLkFWWqrSYS7heVazHY0PLAHLv9kc
debug3: write ERROR from cb(2):232, io:036C7F60
Unable to add key ECDSA-SK SHA256:5LcIzOcB+xUWRtv49sYVzUML2msfJEcSWWMnClmgmiE
debug3: write ERROR from cb(2):232, io:036C7F60
Unable to add key ECDSA-SK SHA256:AObzDO385FWMH7UOCD/f33qsxRcf9RT1rqVDDIufC4I

Using Win10 PowerShell (as administrator) .

netmiller avatar Jan 25 '23 12:01 netmiller

using Win10 with OpenSSH_for_Windows_9.1p1, LibreSSL 3.6.1 and loading resident keys from secure-key :

PS C:\Users\esa> ssh-add -K -S internal -vvv
Enter PIN for authenticator:
debug1: find_helper: using "C:\\Program Files (x86)\\OpenSSH\\ssh-sk-helper.exe" as helper
debug3: Creating process with CREATE_NO_WINDOW
debug3: spawning "C:\\Program Files (x86)\\OpenSSH\\ssh-sk-helper.exe" as subprocess
debug3: start_helper: started pid=2900
debug3: ssh_msg_send: type 5
debug3: ssh_msg_recv entering
debug1: client_converse: helper returned error -4
debug3: reap_helper: pid=2900
Unable to load resident keys: invalid format

any idea what caused this invalid format ?? Key type used is " -t ecdsa-sk" and keygen does not raise any errors.

Same problem here on Windows 11

kaisengit avatar Mar 16 '23 10:03 kaisengit

Same issue win11 as well, any update?

anaxmedia avatar May 02 '23 21:05 anaxmedia

Both ssh-add -K -S internal (with agent come with OpenSSH for Windows) and ssh-keygen -K work fine in an elevated cmd or PowerShell. But in an unprivileged shell, it will cause the error as follows (which is the same as the post above):

>ssh-add -K -S internal -vvvv
Enter PIN for authenticator:
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=9376
debug3: ssh_msg_send: type 5
debug3: ssh_msg_recv entering
debug1: client_converse: helper returned error -4
debug3: reap_helper: pid=9376
Unable to load resident keys: invalid format

I'm using the latest OpenSSH for Windows (9.2.2.0p1-Beta) as of now. It seems that the key is only readable with Admin privileges. Maybe it has nothing to do with OpenSSH but rather how Windows manages FIDO keys? Because I see the same behaviour when using ykman:

>ykman fido credentials list
ERROR: FIDO access on Windows requires running as Administrator. 

x-magic avatar Jun 01 '23 17:06 x-magic

I ran into this too. The new Yubico Authenticators do it better: When started as normal users they say "WebAuthn management requires elevated privileges." You click on "unlock" and get asked for elevated rights.

Interestingly this does not apply for managing the PIV-portion of the key.

First priority is to show a meaningful error message. The current one is not.

Better would be not to require admin rights to manage a USB key. Because this excludes normal users to apply strong security and it propagates unnecessary use of admin rights. Resident keys were created with the purpose of being visible to everybody so why require admin rights to list them? An "attacker" can just plug the USB key to another computer under his control and list the passkeys there.

robinschwab avatar Jan 17 '24 21:01 robinschwab