Giles Orr wrote:
A couple days ago I discovered the joys of SSH agent forwarding. But with that, I discovered this warning in the man page: "Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent's UNIX-domain socket) can access the local agent through the forwarded connection. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent." I've read this about five times because as far as I can tell, all it's actually saying is "you need to trust your remote system." So please correct me if I'm wrong: it's saying that IF someone on the remote system has a privilege escalation (or is root), then they can authenticate using any keys in your agent (but not get the keys). Is that correct?
Yes, that's what it's saying.
And today I found this:
https://heipei.github.io/2015/02/26/SSH-Agent-Forwarding-considered-harmful/
He attacks with "It is meant as an easy way to connect to a host A with your SSH key and from there connect to another host B with that same key. This obviously is only needed if you cannot connect to host B directly from your workstation."
I was immediately scratching my head, because my use-case is to load my keys on my workstation, then SSH to a remote host where I do git and/or ansible stuff that needs a key. I can connect to "host B" (the git host) from "my workstation," but the work is better done on "host A." With agent forwarding, I don't have to store the private key on the remote machine, or (re)load an SSH key.
There can be a few reasons to ssh-with-forwarding to host A and then connect from there to other hosts; one is that you can't SSH directly to host B and have to go to A first (their case), a second is that A is where your files are and you want to push/pull from there to the other boxen (your case), a third is that the link from your workstation keeps dropping, the workstation crashes, and/or you don't have bandwidth from it to host A (I've run into all of these at various points) so you want to run screen on host A and work from that and only have to reconnect to it if your link breaks (knowing how to get the new connection's SSH_AUTH_SOCK into screen's environment is a Useful Thing). There may be further use cases. In their case, if you don't trust host A, it is possible to first SSH to it with a local-port-forwarding listening on localhost:whateverport on your workstation to forward to hostB:22 from the host A end, and then fire off a second SSH through that forwarding to host B. Of course, this loses the benefits of being able to talk to host B from host A. -- Anthony de Boer