SSH Agent Forwarding: When Convenience Meets Risk

The problem: keys stuck on the client

You have a private key on your laptop and need to reach a production server that sits behind a bastion host. Copying the key to the bastion works, but it spreads secret material to a machine you may not fully control. SSH agent forwarding promises to keep the key on your laptop while still letting the bastion authenticate onward connections.

How agent forwarding works

When you start an SSH agent (ssh-agent) and add a key (ssh-add), the agent holds the decrypted private key in memory. With ForwardAgent yes (or the -A flag) the client asks the server to forward the agent's UNIX‑domain socket over the encrypted channel. The remote sshd creates a proxy socket (typically $SSH_AUTH_SOCK) that any process on the remote host can use to request signatures from your local agent. The private key never leaves the client.

Worked example: bastion → target

1. Start the agent and load your key (run on your laptop):

   eval "$(ssh-agent -s)"
   ssh-add ~/.ssh/id_ed25519   # enter passphrase if set

   Permissions: your user account; the agent socket is created with mode 0600.
2. Connect to the bastion with forwarding enabled:

   ssh -A [contact removed] -vv

   Check: in the verbose output look for SSH2_MSG_USERAUTH_REQUEST with method publickey and a line like sign_and_send_pubkey: signing using ssh-ed25519. This confirms the client used the local agent.
3. From the bastion, hop to the target server:

   ssh [contact removed] -vv

   Check: the same sign_and_send_pubkey line appears, but now the signature request originates from the bastion's forwarded socket.
4. Verify the key is visible on the target:

   ssh-add -l

   The output should list the fingerprint of id_ed25519, proving the agent was forwarded end‑to‑end.

Security trade‑offs

• Any process on the forwarded host can query the agent. A compromised bastion (or a malicious user sharing the same account) can request signatures for any key the agent holds, effectively granting it access to every downstream host you can reach.
• Forwarding is disabled by default on many hardened servers. Administrators must explicitly set AllowAgentForwarding yes in /etc/ssh/sshd_config or per‑user ~/.ssh/authorized_keys with the no-agent-forwarding option omitted. Accidentally enabling it on a shared jump box widens the attack surface.
• Older OpenSSH releases (pre‑8.7) had a bug that ignored ForwardAgent no. Ensure both client and server run ≥ 8.7p1.
• Passphrase‑protected keys do not mitigate a compromised agent. The agent holds the decrypted key; an attacker with socket access can use it without knowing the passphrase.

Mitigation checklist

Host *
  ForwardAgent no

Host bastion.example.com
  ForwardAgent yes

AllowAgentForwarding no
Match Host bastion.example.com
  AllowAgentForwarding yes

ssh -J [contact removed] [contact removed]

eval "$(ssh-agent -s -a $HOME/.ssh/agent-bastion)"
ssh-add ~/.ssh/id_ed25519
ssh -o IdentityAgent=$HOME/.ssh/agent-bastion -A [contact removed]

How to verify a restriction works

Add ForwardAgent no for a specific host in your ~/.ssh/config and attempt a connection with -A:

Host untrusted.example.com
  ForwardAgent no

Run ssh -A [contact removed]. The client should abort with Agent forwarding disabled (or similar) and the verbose log will show debug1: agent forwarding disabled. This confirms the setting is honored.

Closing action

Adopt a default‑deny stance: keep ForwardAgent no globally, whitelist only the bastion hosts you explicitly manage, and prefer ProxyJump so the client never opens a shell on the intermediate host. Run the verification step above after any config change, and audit AllowAgentForwarding on servers quarterly. The convenience of agent forwarding is real, but the risk is proportional to the trust you place in every process that can reach the forwarded socket.