5 ms·

My need for agent forwarding has almost completely vanished since `ProxyJump` was added a few years ago. Host *.example.com User runlevel1 IdentityFi

My need for agent forwarding has almost completely vanished since `ProxyJump` was added a few years ago. Host *.example.com User runlevel1 IdentityFile ~/.ssh/id_rsa-foo ProxyJump foo@jump.example.com So when I SSH to qux.example.com, it first SSHs to foo@jump.example.com then through it to runlevel1@qux.example.com and my agent is used on each individually. So there's no ssh-agent socket on the intermediate jump box. EDIT: More examples here: https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Proxies_and_Jump_Hosts https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Proxies_and_J... EDIT2: For folks stuck on older SSH clients, you can do this with `ProxyCommand ssh -W ...` instead (also shown in the previous link) which is actually what ProxyJump is doing under-the-hood anyhow. https://github.com/openssh/openssh-portable/blob/d9dbb5d/ssh.c#L1233 https://github.com/openssh/openssh-portable/blob/d9dbb5d/ssh...

deleted 5y ago
[deleted]
PeterWhittaker 5y ago
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.
- 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.
rsync 5y ago
Related: My favorite simple VPN, sshuttle[1], can use ProxyJump to traverse a "chain" of hosts: https://github.com/sshuttle/sshuttle/issues/340#issuecomment-594646967 https://github.com/sshuttle/sshuttle/issues/340#issuecomment... [1] https://github.com/sshuttle/sshuttle https://github.com/sshuttle/sshuttle
- deleted 5y ago
  [deleted]
- Too 5y ago
  Sshuttle is amazing. I usually loathe vpn clients and all that surrounds them, especially when set up by bigco IT that treats Linux as second class citizen. sshuttle is such a breeze, it’s literally a single command that just works instantly, together with hardware keys you get 2fa without some vendor specific vpn auth app on your phone.
  - aborsy 5y ago
    Can sshuttle be run from a phone using a terminal?
    - wildlogic 5y ago
      yes.
nimish 5y ago
ProxyJump absolutely rules. Much, much simpler than dealing with agent forwarding which is janky even at the best of times.
- ed25519FUUU 5y ago
  Why is it jenky? It just makes it so your ssh-agent is available on a remote host. It does exactly what it’s supposed to do.
  - nimish 5y ago
    A root user on the jump box can intercept data. https://news.ycombinator.com/item?id=19643977 https://news.ycombinator.com/item?id=19643977 is a nice explanation. The jump box is used only to establish a tunnel and you don't have to deal with multiple agents communicating.
tarkin2 5y ago
What's the usecase?
- runlevel1 5y ago
  Jumping through a bastion host.
ed25519FUUU 5y ago
One really obvious use-case for this which cannot be solved with proxyjump is pushing and pulling via git on a remote dev box.
- INTPenis 5y ago
  Can you clarify this statement? Because I push and pull git over SSH ProxyJump regularly.
  - mjochim 5y ago
    When the working copy of your git repo resides on a remote box R1 rather than your local machine. You want to ssh into the R1, edit files and commits there and then push from there to some other remote host R2. Meanwhile your private key for accessing R2 is on your local machine. R1 can only access your forwarded agent, but not your private key. ProxyJump doesn't help you here because R1 does much more than just proxy your SSH connection.
stavros 5y ago
I love you. So this basically forwards the port itself through each host? Intermediates never access your SSH keys, right?

deleted 5y ago

[deleted]

PeterWhittaker 5y ago

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.
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.

rsync 5y ago

Related: My favorite simple VPN, sshuttle[1], can use ProxyJump to traverse a "chain" of hosts: https://github.com/sshuttle/sshuttle/issues/340#issuecomment-594646967 https://github.com/sshuttle/sshuttle/issues/340#issuecomment... [1] https://github.com/sshuttle/sshuttle https://github.com/sshuttle/sshuttle

deleted 5y ago
[deleted]
Too 5y ago
Sshuttle is amazing. I usually loathe vpn clients and all that surrounds them, especially when set up by bigco IT that treats Linux as second class citizen. sshuttle is such a breeze, it’s literally a single command that just works instantly, together with hardware keys you get 2fa without some vendor specific vpn auth app on your phone.
- aborsy 5y ago
  Can sshuttle be run from a phone using a terminal?
  - wildlogic 5y ago
    yes.

nimish 5y ago

ProxyJump absolutely rules. Much, much simpler than dealing with agent forwarding which is janky even at the best of times.

ed25519FUUU 5y ago
Why is it jenky? It just makes it so your ssh-agent is available on a remote host. It does exactly what it’s supposed to do.
- nimish 5y ago
  A root user on the jump box can intercept data. https://news.ycombinator.com/item?id=19643977 https://news.ycombinator.com/item?id=19643977 is a nice explanation. The jump box is used only to establish a tunnel and you don't have to deal with multiple agents communicating.

tarkin2 5y ago

What's the usecase?

runlevel1 5y ago
Jumping through a bastion host.

ed25519FUUU 5y ago

One really obvious use-case for this which cannot be solved with proxyjump is pushing and pulling via git on a remote dev box.

INTPenis 5y ago
Can you clarify this statement? Because I push and pull git over SSH ProxyJump regularly.
- mjochim 5y ago
  When the working copy of your git repo resides on a remote box R1 rather than your local machine. You want to ssh into the R1, edit files and commits there and then push from there to some other remote host R2. Meanwhile your private key for accessing R2 is on your local machine. R1 can only access your forwarded agent, but not your private key. ProxyJump doesn't help you here because R1 does much more than just proxy your SSH connection.

stavros 5y ago

I love you. So this basically forwards the port itself through each host? Intermediates never access your SSH keys, right?