No, part of this involved using Windows's Data Protection API to decrypt it.
Other non-administrator users can't read these registry keys, it's encrypted with the login password (as is common with macOS Keychain and GNOME/KDE's credential stores) so even other administrators can't decrypt it.
On Linux, administrators (root) can extract the keys from ssh-agent. This is actually no less secure and usually more secure.
This is a cool demo of how to do it on Windows, and there's a reason the author didn't call it a vulnerability - it's working as designed and this form of attack is outside the intended threat model.
>On Linux, administrators (root) can extract the keys from ssh-agent.
I don't understand how the situation is different. Of course you can extract the keys from a running ssh-agent since the whole point is not having to provide your password every time so they have to have access to the private key one way or an other. How is the situation different on Windows? Surely when the user is logged an administrator with access to the full RAM and storage will be able to piece everything together (like TFA does for instance)?
On the other hand if you really can't trust your admin you have a huge problem anyway, even with a HSM you could be phished very easily.
Actually overall I'd say that this Windows method is slightly less secure because it means that the Windows keychain thingy is a single point of failure, if somebody compromises it they have access to everything including the ssh keys in the registry.
I don't think Windows gives an administrator account unfettered access to the full RAM, no. And without that or the user's login password, all they could get from the registry is the encrypted version, just as on disk. The encryption is separate per-user with that user's password.
Of course there may be ways to get an even more advanced level of access than administrator, such as the system account, but honestly Windows does lock some things down really hard at the kernel level and Data Protection decryption based on in-RAM credentials might be one. I don't know modern Windows internals to that level.
>I don't think Windows gives an administrator account unfettered access to the full RAM, no.
Are you sure? Typically root has access to the full RAM on an unx system. Unless this is linked to a hardware TPM module I'm not sure why and how it would be protected. Maybe I'm wrong to assume that Windows Administrator == unx root?
Anyway, if the OS has a way to hide some of its state from even the admin then surely it could use it to hide the unencrypted SSH key in RAM instead of hiding the key-to-the-registry-key? My main argument is that at some point if the OS doesn't want to prompt the user for a password it must have access to the private key one way or an other, so I'm not convinced that Windows is more (or less) secure than Linux in this situation.
If you're admin, you might have to install a driver to scrape all memory. So... one hoop to jump through :)
Caveat: you're still trapped in your hypervisor partition. Enclaves (e.g. SGX) are also protected from admin/root snooping. IIRC, this is the same as on Linux.
It's protected by DPAPI [0] which uses the user's password to encrypt the keys. Any other programs running under that user can theoretically access it (just like how any program can access your ~/.ssh/id_rsa) but other users shouldn't be able to access it.
~/.ssh/id_rsa can be protected by a password, you'll want to access the running ssh-agent process memory to get the key in cleartext (unless the person use some security token in which case you can't access the key, just try to login on a remote computer directly while the HSM is available).
But while ssh-agent has the key unlocked on a Linux system, any process running as that user can use the key without knowing the passphrase the ssh-agent. That's the more direct comparison.
Other non-administrator users can't read these registry keys, it's encrypted with the login password (as is common with macOS Keychain and GNOME/KDE's credential stores) so even other administrators can't decrypt it.
On Linux, administrators (root) can extract the keys from ssh-agent. This is actually no less secure and usually more secure.
This is a cool demo of how to do it on Windows, and there's a reason the author didn't call it a vulnerability - it's working as designed and this form of attack is outside the intended threat model.