[GTALUG] SSH Agent Forwarding

[Anthony de Boer]

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