3 ms·

Agreed. What worries me is this statement: “While it is generally better for users to avoid the use of a forwarded agent altogether (e.g. using the ProxyJump di

Agreed. What worries me is this statement: “While it is generally better for users to avoid the use of a forwarded agent altogether (e.g. using the ProxyJump directive), the agent protocol itself has offered little defence against this sort of attack.” Which I cynically read as “Hey, there is a better way, but we’re going to try to make the worse way slightly more secure, here’s how!” Some of the described behaviours strike me as opening up entirely new and hard-to-detect attack vectors.

ed25519FUUU 5y ago
There’s completely valid use-cases for which ProxyJump makes no sense. For example forwarding your SSH agent to a remote dev box so that you can push and pull from git.
- jeltz 5y ago
  ProxyJump also does not support pam_ssh_agent_auth which can be used for e.g. implementing sudo auth with ssh keys. ProxyJump only solves a small subset of what agent forwarding can be used for.
- geofft 5y ago
  Huh, what I usually do is generate a new SSH key on the dev box and enroll it. That means if the dev box gets compromised, first, it can't access anything other than my git server, and second, I have independent audit logs of actions from my dev box's key. What's the advantage of using SSH agent forwarding over either generating a new key (if you don't quite trust the remote box) or scp'ing your private key (if you do trust the remote box just as much as your local one)?
  - mjochim 5y ago
    If you don’t really trust the remote box, then storing a key on it – even one created solely for that box – might not be a good option. Doesn’t really matter whether the key is completely and permanently unencrypted or you only decrypt it during use. To my understanding, by forwarding the SSH agent you can keep the private material on the local box only. I’d have to read up the details before I could be sure this is true, but that’s also what the linked article says: > The [...] ssh-agent [...] supports [...] a way to forward access to private keys to remote hosts, without exposing the private keys themselves. Creating a separate private key solely for this box – but storing it locally – is then a measure you can take additionally.
    - raffraffraff 5y ago
      When you're forwarding an agent the material itself is kept on your local client, but if someone has root on the server that your agent is forwarded to, they can hijack your ssh-agent socket and ssh to any other server "as you", and your local ssh-agent will comply with the request and forward the key. There's a "lesser of two evils" argument you could make: by using a separate key that only has rights to git, you're protecting your "main" ssh identity from being hijacked. So the only thing they can do if they compromise the server is impersonate you on git. ...Exactly, that's arguably as bad as it gets. If you don't trust the jump box, do not use it. I had to use a "meh" jump box in a previous job. It was locked down to an extent, but a bunch of people could easily get root on it. Since I had to be active on that box for a bunch of work (not just "passing through" for the duration of a git pull) I set a very short lifetime on my ssh-add, so I got prompted for my passphrase whenever it expired and a key was requested. Not great, but better than leaving it active continually while I'm connected.
  - tedunangst 5y ago
    Nobody can break into the dev box and steal the key while you're away on vacation for two weeks.
    - geofft 5y ago
      But they can break into the dev box and inject malware (where by "malware" I mean like 'echo alias ssh=/tmp/evil-ssh >> ~/.bashrc') while I'm on vacation for two weeks, though? And if I wasn't going to notice them breaking in while I'm away on vacation, can't they just break in again as soon as I return from vacation? A computer isn't like a house. You don't inherently notice people breaking in when you're using it: they don't make sounds or show up in your line of sight. And you don't inherently fail to notice people breaking in when you're not: if there are logs (that get sent off the machine), there will still be logs when you get back. Digital burglars don't have any need to "scope out" your machine and "wait" for you to be on vacation. That's why I think the ssh-agent model provides a false reassurance. The fact that you're actively connected to the machine doesn't make attacks any less likely, but it sure feels that way, and so you're likely to forward an agent to a machine where you wouldn't be comfortable forwarding the raw key - but you shouldn't be comfortable forwarding the agent either.
marcosdumay 5y ago
That's exactly what it says. Like X11 forwarding, there are cases where agent forwarding is secure and cases where it's not, and unless the alternatives completely eliminate the need for this feature, improving it is always good.

ed25519FUUU 5y ago

There’s completely valid use-cases for which ProxyJump makes no sense. For example forwarding your SSH agent to a remote dev box so that you can push and pull from git.

jeltz 5y ago
ProxyJump also does not support pam_ssh_agent_auth which can be used for e.g. implementing sudo auth with ssh keys. ProxyJump only solves a small subset of what agent forwarding can be used for.
geofft 5y ago
Huh, what I usually do is generate a new SSH key on the dev box and enroll it. That means if the dev box gets compromised, first, it can't access anything other than my git server, and second, I have independent audit logs of actions from my dev box's key. What's the advantage of using SSH agent forwarding over either generating a new key (if you don't quite trust the remote box) or scp'ing your private key (if you do trust the remote box just as much as your local one)?
- mjochim 5y ago
  If you don’t really trust the remote box, then storing a key on it – even one created solely for that box – might not be a good option. Doesn’t really matter whether the key is completely and permanently unencrypted or you only decrypt it during use. To my understanding, by forwarding the SSH agent you can keep the private material on the local box only. I’d have to read up the details before I could be sure this is true, but that’s also what the linked article says: > The [...] ssh-agent [...] supports [...] a way to forward access to private keys to remote hosts, without exposing the private keys themselves. Creating a separate private key solely for this box – but storing it locally – is then a measure you can take additionally.
  - raffraffraff 5y ago
    When you're forwarding an agent the material itself is kept on your local client, but if someone has root on the server that your agent is forwarded to, they can hijack your ssh-agent socket and ssh to any other server "as you", and your local ssh-agent will comply with the request and forward the key. There's a "lesser of two evils" argument you could make: by using a separate key that only has rights to git, you're protecting your "main" ssh identity from being hijacked. So the only thing they can do if they compromise the server is impersonate you on git. ...Exactly, that's arguably as bad as it gets. If you don't trust the jump box, do not use it. I had to use a "meh" jump box in a previous job. It was locked down to an extent, but a bunch of people could easily get root on it. Since I had to be active on that box for a bunch of work (not just "passing through" for the duration of a git pull) I set a very short lifetime on my ssh-add, so I got prompted for my passphrase whenever it expired and a key was requested. Not great, but better than leaving it active continually while I'm connected.
- tedunangst 5y ago
  Nobody can break into the dev box and steal the key while you're away on vacation for two weeks.
  - geofft 5y ago
    But they can break into the dev box and inject malware (where by "malware" I mean like 'echo alias ssh=/tmp/evil-ssh >> ~/.bashrc') while I'm on vacation for two weeks, though? And if I wasn't going to notice them breaking in while I'm away on vacation, can't they just break in again as soon as I return from vacation? A computer isn't like a house. You don't inherently notice people breaking in when you're using it: they don't make sounds or show up in your line of sight. And you don't inherently fail to notice people breaking in when you're not: if there are logs (that get sent off the machine), there will still be logs when you get back. Digital burglars don't have any need to "scope out" your machine and "wait" for you to be on vacation. That's why I think the ssh-agent model provides a false reassurance. The fact that you're actively connected to the machine doesn't make attacks any less likely, but it sure feels that way, and so you're likely to forward an agent to a machine where you wouldn't be comfortable forwarding the raw key - but you shouldn't be comfortable forwarding the agent either.

marcosdumay 5y ago

That's exactly what it says. Like X11 forwarding, there are cases where agent forwarding is secure and cases where it's not, and unless the alternatives completely eliminate the need for this feature, improving it is always good.