SSH Agent Forwarding Exploitation

Summary

What can you do if the system-wide SSH client configuration (commonly /etc/ssh/ssh_config) or $HOME/.ssh/config contains the following directive?^[3]

ForwardAgent yes

ForwardAgent yes forwards the authentication agent to the remote host for matching connections. If you have root on an intermediate host where another user’s agent was forwarded, you can access the forwarded Unix-domain socket and ask that agent to authenticate with its loaded identities; this can let you access hosts where those identities are authorized.^[1][2][3]

Useful socket hunting commands on Linux systems include (the exact socket directory depends on the client and forwarding setup):^[1][2]

ls -la /run/user/*/ssh-* /tmp/ssh-* 2>/dev/null
find /run/user /tmp -type s -name 'agent.*' 2>/dev/null

If you have access to Bob’s forwarded socket, use it for an SSH connection:^[1][2]

SSH_AUTH_SOCK=/tmp/ssh-haqzR16816/agent.16816 ssh bob@boston

Why does this work?

Setting SSH_AUTH_SOCK points the SSH client at a Unix-domain socket for the agent; it does not load Bob’s private-key file. The agent performs private-key operations itself and returns the result, rather than sending private-key material to the client or over the network.^[1][2]

If Bob has already loaded a key into the agent and that key is authorized on another host, anyone who can use the socket can ask the agent to authenticate there as Bob without knowing the key’s passphrase at request time; confirmation and destination constraints may still limit the request.^[1][2][4]

Access to the socket is normally enough; extracting key material from the agent process is unnecessary and is not part of the agent protocol. The owning user or root may be able to bypass socket permissions, so protect hosts receiving forwarded agents accordingly.^[2][3]

Long explanation and exploitation

Read Clockwork’s original research.^[1]

References

• [1] SSH Agent Hijacking
• [2] ssh-agent(1)
• [3] ssh_config(5)
• [4] ssh-add(1)