3 ms·

Thanks for this. Wanted to put in a pitch for Dima Kogan's more-secure way of doing ssh-agent forwarding: https://github.com/StanfordSNR/guardian-agent https://

Thanks for this. Wanted to put in a pitch for Dima Kogan's more-secure way of doing ssh-agent forwarding: https://github.com/StanfordSNR/guardian-agent https://github.com/StanfordSNR/guardian-agent It works with SSH and Mosh. The basic idea is that before agreeing to a request, the principal or their agent should know (a) what machine is asking, (b) what remote machine they want to connect to, and (c) what command line they want to run on the principal's behalf. And the principal's authorization should then be limited to that context. The ssh-agent protocol doesn't give the agent any of that information; it's really just intended for local SSH-like processes to ask "please sign this blob so I can connect somewhere" without them having to see the plaintext private key. Forwarding that to untrusted remote machines isn't ideal. It turns out an agent can get access to this information and limit the scope of authorization in a mostly[1] backwards-compatible way, which is how guardian-agent works, but imo it would be preferable if a future version of the SSH protocol were designed more expressly for secure agent forwarding. [1] For (c), the remote server has to be OpenSSH because guardian-agent relies on a nonstandard extension.

mmalone 6y ago
YES. It would be so easy for OpenSSH to fix agent forwarding. Just need to limit authority and/or ask for consent for a particular action.
- undecidabot 6y ago
  You can configure ssh-agent to ask for confirmation if you set the `-c` flag in ssh-add or by setting `AddKeysToAgent` to `confirm` in your ssh config [1]. Once set, authentication will require confirmation via a GUI dialog provided by the ssh-askpass command. However, it does not mention the command or process requesting for authentication. It works great on Linux, but I couldn't get it to work on macOS with the system keychain. [1] https://man.openbsd.org/ssh_config.5#AddKeysToAgent https://man.openbsd.org/ssh_config.5#AddKeysToAgent
  - mmalone 6y ago
    Recent macOS versions don't have `ssh-askpass`, and it's weirdly hard to add one. Since agent confirmation depends on askpass, I don't think there's an easy way to get this work on macOS. Aside from the missing context you mentioned, the other bigger problem with this approach is that agent confirmation is all-or-nothing: it turns on confirmation for local SSH connections in addition to forwarded connections. If you're using SSH a lot, having to confirm every connection is very annoying.
inetknght 6y ago
> The basic idea is that before agreeing to a request, the principal or their agent should know (a) what machine is asking, (b) what remote machine they want to connect to, and (c) what command line they want to run on the principal's behalf. And the principal's authorization should then be limited to that context. Holy snap this is exactly the reason that I've gone to great lengths to disable SSH Agents and askpass. Asking for a password without any context whatsoever of exactly which process is wanting it is a nightmare
tialaramex 6y ago
At first glance guardian-agent seems to be focused on a happy path where the remote systems are honest. Clearly agent forwarding attacks would mostly involve dishonest (or at least corrupt) remote systems and if guardian-agent specifically defeats that rather than just punting I don't see how in this summary.
- keithwinstein 6y ago
  For guardian-agent to live up to its security claims, it needs to correctly deny requests on the "unhappy path." So yeah, that's a primary goal. As far as we know it lives up to that. Requests are locked to (a) [identity of requesting machine] because their origin is tagged by the local (trusted) code, which got to see the requesting machine's public key when it connected. They're locked to (b) [remote machine] by having the local code see the remote machine's public key. And they're locked to (c) [command] by having the local code be the one to send the command and then "no-more-sessions" and get confirmation before handing over control to the requesting machine.

mmalone 6y ago

YES. It would be so easy for OpenSSH to fix agent forwarding. Just need to limit authority and/or ask for consent for a particular action.

undecidabot 6y ago
You can configure ssh-agent to ask for confirmation if you set the `-c` flag in ssh-add or by setting `AddKeysToAgent` to `confirm` in your ssh config [1]. Once set, authentication will require confirmation via a GUI dialog provided by the ssh-askpass command. However, it does not mention the command or process requesting for authentication. It works great on Linux, but I couldn't get it to work on macOS with the system keychain. [1] https://man.openbsd.org/ssh_config.5#AddKeysToAgent https://man.openbsd.org/ssh_config.5#AddKeysToAgent
- mmalone 6y ago
  Recent macOS versions don't have `ssh-askpass`, and it's weirdly hard to add one. Since agent confirmation depends on askpass, I don't think there's an easy way to get this work on macOS. Aside from the missing context you mentioned, the other bigger problem with this approach is that agent confirmation is all-or-nothing: it turns on confirmation for local SSH connections in addition to forwarded connections. If you're using SSH a lot, having to confirm every connection is very annoying.

inetknght 6y ago

> The basic idea is that before agreeing to a request, the principal or their agent should know (a) what machine is asking, (b) what remote machine they want to connect to, and (c) what command line they want to run on the principal's behalf. And the principal's authorization should then be limited to that context. Holy snap this is exactly the reason that I've gone to great lengths to disable SSH Agents and askpass. Asking for a password without any context whatsoever of exactly which process is wanting it is a nightmare

tialaramex 6y ago

At first glance guardian-agent seems to be focused on a happy path where the remote systems are honest. Clearly agent forwarding attacks would mostly involve dishonest (or at least corrupt) remote systems and if guardian-agent specifically defeats that rather than just punting I don't see how in this summary.

keithwinstein 6y ago
For guardian-agent to live up to its security claims, it needs to correctly deny requests on the "unhappy path." So yeah, that's a primary goal. As far as we know it lives up to that. Requests are locked to (a) [identity of requesting machine] because their origin is tagged by the local (trusted) code, which got to see the requesting machine's public key when it connected. They're locked to (b) [remote machine] by having the local code see the remote machine's public key. And they're locked to (c) [command] by having the local code be the one to send the command and then "no-more-sessions" and get confirmation before handing over control to the requesting machine.