ssh-agent certicates not loading id

[cdstg]

"OpenSSH for Windows" version
7.7.2.1
Client OperatingSystem
Windows 10 Home 1809
What is failing
When I have both a cert and a id eg like
id_rsa
id_rsa-cert ( ecdsa versions )
it says loaded eg
ssh-add
It says added Key and Cert

Identity added: C:\Users\Asus/.ssh/id_rsa (C:\Users\Asus/.ssh/id_rsa)
Certificate added: C:\Users\Asus/.ssh/id_rsa-cert.pub (vault-root-:xxxxxx)

BUT only adds the cert

PS C:\Users\Asus> ssh-add -l
2048 SHA256:Em8Fxxxxxxx C:\Users\Asus/.ssh/id_rsa (RSA-CERT)

if I do this in Ubuntu even on WSL it works as expected even with older versions of openssh

Expected output
ssh-add -l
2048 SHA256::Em8Fxxxxxxx /home/craig/.ssh/id_rsa (RSA)
2048 SHA256::Em8Fxxxxxxx /home/craig/.ssh/id_rsa (RSA-CERT)

Actual output
PS C:\Users\Asus> ssh-add -l
2048 SHA256:Em8Fxxxxxxx C:\Users\Asus/.ssh/id_rsa (RSA-CERT)

Any ideas while on native version is does not work ?

[NoMoreFood]

Can you verify this is still an issue with the latest version? Seems to works for me:

C:\Users\Bryan Berns\.ssh>ssh-add
Identity added: C:\Users\Bryan Berns/.ssh/id_rsa (C:\Users\Bryan Berns/.ssh/id_rsa)
Certificate added: C:\Users\Bryan Berns/.ssh/id_rsa-cert.pub (user_berns)

C:\Users\Bryan Berns\.ssh>ssh-add -l
2048 SHA256:TL+xy1N/lJW+Rh7zMOH7S+qH/npdQ03UVYtoUO8Mbx4 bryan berns@BERNS-WINDOWS (RSA)
2048 SHA256:ZhLjgW3nju/JhhhTIYvV73wj2gFDF55zHdI2VuuHdWQ C:\Users\Bryan Berns/.ssh/id_rsa (RSA-CERT)

[cdstg]

Ok let me try the latest
BTW what version were you running
ssh -V

[NoMoreFood]

7.9 albeit my version was built from source.

[manojampalam]

@NoMoreFood interesting, I'm seeing this behavior in 7.9 too (only cert is reported).

@cdstg will see what's the difference between the Unix and Windows versions of ssh-agent. Otherwise, why would you need both of them listed? Even if only the cert is listed, AFAIK, it should work in cases where the public key is "authorized" on the server. No?

[NoMoreFood]

@manojampalam Yup, ignore my last comment. Some other application had decided to dump a copy of ssh-add.exe in my system directory and it had precedence over the OpenSSH copy in my path. Are you looking into this one? If not, I'll take a look.

UPDATE: It was not the other binary "fixing" the issue but simply the fact I had previously added a key and it was stuck in the registry.

[cdstg]

@NoMoreFood interesting, I'm seeing this behavior in 7.9 too (only cert is reported).

@cdstg will see what's the difference between the Unix and Windows versions of ssh-agent. Otherwise, why would you need both of them listed? Even if only the cert is listed, AFAIK, it should work in cases where the public key is "authorized" on the server. No?

No you need the private key to be loaded in the agent as well as the cert is a public cert
The cert only has info like how long its valid and what principles are valid

Linux version is doing that and can connect fine and I tried on only linux versions and newer ones
WSL also works

I tried on different windows versions all the same issue and even with the 7.9 :-(

[NoMoreFood]

@cdstg So the reason they both don't show up is because the entries are stored in HKCU\Software\OpenSSH\Agent\Keys\SHA256:HASH and the HASH is the same for both entries. The RSA entry is being overwritten by the RSA-CERT entry. Can you try the following, please:

1. Move the -cert.pub file to another directory.
2. Run ssh-add
3. Append '-Alt' to entry in the aforementioned registry key.
4. Restart the service.
5. Move -cert.pub back
6. Run ssh-add
7. Run ssh-add -l
8. Verify ssh operates as expected.

If that works, we can explore better solutions.

UPDATE: If you want to try a potential fix yourself, see: NoMoreFood/openssh-portable@d7b6489

[NoMoreFood]

If interested, you can test using these binaries: https://github.com/NoMoreFood/openssh-portable/releases/tag/v7.9-merge-1

[chambaw]

Not sure. This is all new to me

…

On Tue, Feb 12, 2019 at 12:03 AM cdstg ***@***.***> wrote: Ok let me try the latest BTW what version were you running ssh -V — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1333 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Ag5WhBW82NUVNLd7zqryeMPB275D6zolks5vMkstgaJpZM4af6bS> .

[stefanfritsch]

@NoMoreFood Thanks a lot. They work great.

@chambaw and other people: You just have to download the OpenSSH-Win64.zip (it's highly unlikely you're running 32bit Windows) from NoMoreFood's releases page, unzip it, open a Powershell Window in the unzipped directory and run

./install-sshd.ps1

That was enough, at least in my case.

[maxsatula]

Same problem in Windows 10, version 21H1, OS Build 19043.1237
OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2

@NoMoreFood 's fix was great but the latest release in that repository was 7.9. Hey, @maertendMSFT you closed the issue without merging that fix upstream in OpenSSH 8.1, would you please? That would be nice to have a properly working OpenSSH implementation out-of-box, rather than sideloading alternative versions from others, or even worse, compiling patched sources on my own.

If I'm not wrong, there is the commit in @NoMoreFood 's repo which addresses the issue:
NoMoreFood/openssh-portable@37845e7

[bagajjal]

@NoMoreFood - Could you please create the PR so I can merge it.

[maxsatula]

I've had a second look at all of this.

First, NoMoreFood's solution allows to add a key + a single certificate per key, but it will have the same problem if there are multiple certificates related to the same key. So the code needs to be rethought rather than just taken as is.

Second, a more global concern, why is all of this designed to use windows registry at first place? The whole point of ssh agent was to never store unencrypted keys anywhere except RAM. If an agent is restarted, all keys should be lost, no persistence is expected. Well, at least that works that way in UNIX and Linux. I don't see any reasons why Windows should be different from that standpoint. Except there is no way to avoid spawning a new ssh-agent.exe process for each request, as noted here #1586 (comment)

Thanks

[maxsatula]

Third, just found out, confirmation option -c seems to be broken. Perhaps, it should go as a separate issue

>ssh-add -k -c
Enter passphrase for C:\Users\username/.ssh/id_ed25519 (will confirm each use):
Could not add identity "C:\Users\username/.ssh/id_ed25519": communication with agent failed

[NoMoreFood]

@bagajjal I agree with @maxsatula's assessment. The code is a potential improvement upon what's there, but it is not what it really needs to be which is why I never submitted it. I also had similar concerns about use of the registry, but wasn't in a position (time-wise) to consider an overhaul.

[maxsatula]

I hate making things even more complicated, but whatever solution it is going to be, if the goal is to have behavior in Windows as close as possible to the original, a command ssh-add -d ... deletes a specified key and all it's associated certificates. Thus, maybe, whatever naming convention will be chosen for the registry keys, it should be easy enough to track connections between keys and certificates to remove them altogether whenever requested.

[maxsatula]

How about this?

The registry key naming convention for private keys stays the same, just the fingerprint returned by sshkey_fingerprint function, no need to append a key type, as it is highly unlikely two different keys may have the same fingerprint regardless they are the same or different types.

The registry key naming convention for certificates is 3 components:

• key fingerprint returned by sshkey_fingerprint function
• a separator, say a colon (:) or space or something, a separator is optional though as SHA256 hash size is known
• a SHA256 hash of the entire binary version (base64 decoded) certificate, not including [email protected] or comment

In this way we'll get rid of registry key name collisions and maintain the relations between keys and certificates at the same time. What do you think?

[tomtastic]

With organisations worldwide increasing their security posture with SSH certificate usage, it's a pity to see this issue still languishing since 2019. It sure makes working on Windows even more painful.