5 ms·

From [1], cited and linked to in TFA: > To do that, we simply start the ssh-agent service (as Administrator) and use ssh-add to store our private key. Did Mic

by slrz 8y ago

From [1], cited and linked to in TFA: > To do that, we simply start the ssh-agent service (as Administrator) and use ssh-add to store our private key. Did Microsoft do some major surgery on the ssh-agent program or am I missing something else? If the agent is started as Administrator, why can I connect to it with my user privileges? And if I do, can other users on the same system do so, too, accessing the same set of keys? [1] https://blogs.msdn.microsoft.com/powershell/2017/12/15/using-the-openssh-beta-in-windows-10-fall-creators-update-and-windows-server-1709/ https://blogs.msdn.microsoft.com/powershell/2017/12/15/using...

Amezarak 8y ago
> And if I do, can other users on the same system do so, too, accessing the same set of keys? No, that's what DPAPI handles. His DPAPI call works because he's decrypting his own credentials.
Someone1234 8y ago
Unprivileged processes can communicate with privileged services. The service itself sometimes controls which user can access which data, but in this case since the encrypted keys are stored in the Current User Registry Hive (NTUSER.DAT) it likely doesn't need to, filesystem permissions handle that. Plus even if another user gained access to your registry hive, the data is encrypted with your context via the Data Protection APIs.
- simias 8y ago
  I'm sure they have a good reason to do it that way but why run a privileged process when per-user processes could do the job just fine? You'd reduce the surface of attack tremendously that way. If somebody finds a flaw in their admin ssh-agent process they potentially have a way to access other people's key or maybe even escalate their privileges.
  - Someone1234 8y ago
    > I'm sure they have a good reason to do it that way but why run a privileged process when per-user processes could do the job just fine? I actually don't know. I was thinking the same thing. Hopefully they have a good reason, because you're right about the attack surface issue.
- joombaga 8y ago
  Wow thanks for this. I never knew the current user registry hive was stored at NTUSER.dat. I've always figured out the user id and navigated through hkey_users.
  - Someone1234 8y ago
    You can actually offline mount NTUSER via "Load Hive" in RegEdit. Very useful if you're working with a backup or older system image and need something out of the user's registry (rather than the system registry stored in C:\Windows\System32\config).
- slrz 8y ago
  > The service itself sometimes controls which user can access which data, Sure, but ssh-agent does not. That's what I was alluding to with "major surgery". Also, while the encrypted keys are stored in the file system or registry, the agent process necessarily has them in unencrypted form. That's the reason for loading keys into the agent in the first place. To have an ssh-agent that can run as a privileged system service with multiple unprivileged clients, you need to extend it to have some notion of client identity and per-user key space. The standard OpenSSH ssh-agent doesn't have that. Users run their own instance each and if you can connect to it, you can use the keys loaded into it. All of them. The agent code at github.com/PowerShell/openssh-portable doesn't look any different to me, at least from a cursory glance. Thus, the decision to run it as a system service seems odd to me. edit: are they hooking into the agent as a PKCS11 provider/"smartcard" and the plaintext keys never even hit the agent's in-memory table, to be queried by all connected clients?
bluesign 8y ago
Because they are using the same ssh-agent also for accessing host keys (for sshd) PS: Also one agent process for all users on machine vs each user running a ssh-agent process

by slrz 8y ago

Amezarak 8y ago

> And if I do, can other users on the same system do so, too, accessing the same set of keys? No, that's what DPAPI handles. His DPAPI call works because he's decrypting his own credentials.

Someone1234 8y ago

Unprivileged processes can communicate with privileged services. The service itself sometimes controls which user can access which data, but in this case since the encrypted keys are stored in the Current User Registry Hive (NTUSER.DAT) it likely doesn't need to, filesystem permissions handle that. Plus even if another user gained access to your registry hive, the data is encrypted with your context via the Data Protection APIs.

simias 8y ago
I'm sure they have a good reason to do it that way but why run a privileged process when per-user processes could do the job just fine? You'd reduce the surface of attack tremendously that way. If somebody finds a flaw in their admin ssh-agent process they potentially have a way to access other people's key or maybe even escalate their privileges.
- Someone1234 8y ago
  > I'm sure they have a good reason to do it that way but why run a privileged process when per-user processes could do the job just fine? I actually don't know. I was thinking the same thing. Hopefully they have a good reason, because you're right about the attack surface issue.
joombaga 8y ago
Wow thanks for this. I never knew the current user registry hive was stored at NTUSER.dat. I've always figured out the user id and navigated through hkey_users.
- Someone1234 8y ago
  You can actually offline mount NTUSER via "Load Hive" in RegEdit. Very useful if you're working with a backup or older system image and need something out of the user's registry (rather than the system registry stored in C:\Windows\System32\config).
slrz 8y ago
> The service itself sometimes controls which user can access which data, Sure, but ssh-agent does not. That's what I was alluding to with "major surgery". Also, while the encrypted keys are stored in the file system or registry, the agent process necessarily has them in unencrypted form. That's the reason for loading keys into the agent in the first place. To have an ssh-agent that can run as a privileged system service with multiple unprivileged clients, you need to extend it to have some notion of client identity and per-user key space. The standard OpenSSH ssh-agent doesn't have that. Users run their own instance each and if you can connect to it, you can use the keys loaded into it. All of them. The agent code at github.com/PowerShell/openssh-portable doesn't look any different to me, at least from a cursory glance. Thus, the decision to run it as a system service seems odd to me. edit: are they hooking into the agent as a PKCS11 provider/"smartcard" and the plaintext keys never even hit the agent's in-memory table, to be queried by all connected clients?

bluesign 8y ago

Because they are using the same ssh-agent also for accessing host keys (for sshd) PS: Also one agent process for all users on machine vs each user running a ssh-agent process