Hacker News Reader

Comment by runlevel1 | Hacker News Reader

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

View on HN

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.

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.

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.

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.

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)?

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.

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.

Nobody can break into the dev box and steal the key while you're away on vacation for two weeks.

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.

My favorite simple VPN, sshuttle[1], can use ProxyJump to traverse a "chain" of hosts:

https://github.com/sshuttle/sshuttle/issues/340#issuecomment...

[1] https://github.com/sshuttle/sshuttle

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.

Can sshuttle be run from a phone using a terminal?

yes.

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

Can you clarify this statement? Because I push and pull git over SSH ProxyJump regularly.

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.

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

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.

A root user on the jump box can intercept data.

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.

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

What's the usecase?

Jumping through a bastion host.

Reply on news.ycombinator.com