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 --- Talk Mailing List [email protected] http://gtalug.org/mailman/listinfo/talk
