How Attackers Pivot Through SSH Agent Forwarding — and How to Detect It

SSH agent forwarding lets you authenticate to a second server through a bastion host without copying your private key to the bastion. Your local SSH agent handles the authentication transparently. For system administrators who manage dozens of servers through a jump box, it removes the friction of managing keys on intermediate hosts.

For an attacker who has compromised the bastion host, it removes the friction of pivoting to every server the current user can reach.

How the attack works

When you connect to a bastion with agent forwarding enabled (ssh -A bastion), your local SSH agent creates a Unix domain socket on the bastion — typically at /tmp/ssh-XXXX/agent.PID. Any process running as your user on the bastion can use that socket to authenticate as you to any server your key can reach.

An attacker with access to the bastion identifies the agent socket by listing /tmp/ssh-*, sets the SSH_AUTH_SOCK environment variable to point at your socket, and now they can SSH to any server you can reach — using your key, as your identity, with your access. No key theft. No password cracking. Just a socket path and an environment variable.

The three detection patterns

Pattern 1: auth.log — same key fingerprint, different source

When the attacker uses your forwarded agent to connect to a downstream server, the downstream server's auth.log records the authentication. The key fingerprint matches your key, but the source IP is the bastion — not your workstation.

The detection: identify SSH authentications where the key fingerprint belongs to a user who is NOT currently logged into the source host. If the authentication timestamp on the downstream server does not correlate with a legitimate session on the bastion, the forwarded agent was hijacked.

Pattern 2: auditd — SSH_AUTH_SOCK manipulation

If auditd is monitoring the SSH agent socket directory, the attacker's access generates an audit event:

-w /tmp/ssh- -p r -k ssh_agent_access

Legitimate forwarded agent use generates reads from the sshd process. Reads from bash, python, or any non-sshd process indicate manual agent socket access — the attacker's fingerprint.

Pattern 3: timing correlation across hosts

Build a cross-host timeline. The gap between bastion authentication and downstream pivot is typically seconds to minutes. If the bastion user who authenticated at T+0:00 does not own the key fingerprint used at T+0:02, the agent was hijacked. This requires centralized log collection and the ability to join authentication events across hosts by timestamp and key fingerprint.

The fix

Disable agent forwarding on bastion hosts unless operationally required. In /etc/ssh/sshd_config:

AllowAgentForwarding no

If agent forwarding is required, use ProxyJump instead — it routes the SSH connection through the bastion without exposing the agent socket on the bastion's filesystem:

ssh -J bastion target-server

ProxyJump creates a TCP tunnel through the bastion. Your agent socket never touches the bastion. The attacker on the bastion cannot hijack what does not exist.

When you investigate lateral movement on Linux hosts, check /tmp/ssh-* for agent socket artifacts. Check auth.log for key fingerprint mismatches across hosts. Check auditd for non-sshd access to agent socket paths. The attacker who pivots through agent forwarding leaves traces at every layer — if you know where to look.