SSH agent forwarding

What agent forwarding is and how it works

The ssh-agent program holds your private keys in memory and signs authentication requests on behalf of ssh. According to the ssh-agent(1) manual, keys and passphrases never go over the network. Agent forwarding extends this to a hop: when you connect to a server with ssh -A, the server gets a channel back to the agent on your machine. From that server you can then run ssh or git against a third host and authenticate with your local keys, without storing a private key on the intermediate server.

On the remote side the forwarded agent appears as a Unix-domain socket whose path is in the SSH_AUTH_SOCK environment variable. Forwarding is off by default: the ssh_config(5) option ForwardAgent defaults to no, -A turns it on for one connection, and -a turns it off. The option also accepts yes, an explicit socket path or the name of a variable that holds the path.

Using it, checking it, and testing safely

Enable forwarding for a single connection, or only for one named host in ~/.ssh/config:

ssh -A build

Host build
    HostName build.example.com
    ForwardAgent yes

To verify what the remote side can see, log in and run echo "$SSH_AUTH_SOCK" and ssh-add -l. With forwarding on, the second command lists the fingerprints of keys from your local agent; without it, the command reports that no agent is reachable. Compare the two cases with ssh -a and ssh -A on a test server.

Limit what a forwarded agent can do. ssh-add -c requires confirmation before each use of a key (through an askpass program), and -t sets a lifetime, such as ssh-add -c -t 1h. In the config, AddKeysToAgent confirm does the same for keys that ssh adds itself. Use ssh-add -l locally to see what is loaded and ssh-add -D to clear everything. See ssh-add(1).

Security implications and common mistakes

The ssh(1) manual is direct: anyone who can bypass file permissions on the remote host, for example root, can reach your agent through the forwarded socket. The manual notes that an attacker cannot obtain the key material itself, but can use the loaded keys to authenticate to any host that accepts them, for as long as the connection stays open. So a single compromised server on the path becomes a way into everything your keys unlock.

Common mistakes: putting ForwardAgent yes under Host *, forwarding to shared or customer-managed machines, and leaving a long-lived session open on a server you do not fully control. Prefer to forward only to hosts you administer, keep keys loaded with a short lifetime, and use confirmation. OpenSSH 8.9 and later also supports destination constraints, ssh-add -h, that limit which hosts a key may be used for; the manual states they bind only cooperating clients and do not stop a key from being forwarded again.

On the server, AllowAgentForwarding in sshd_config(5) defaults to yes.

Agent forwarding in a hardened setup

The ssh(1) manual itself names the safer alternative: a jump host. With ProxyJump your client connects through the intermediate machine, and the authentication to the final server happens end to end from your own computer, so the intermediate host never gets an agent socket.

Host bastion
    HostName jump.example.com
    User ops

Host app
    HostName 10.0.0.12
    ProxyJump bastion

This is the pattern described under bastion host. Keep AllowTcpForwarding enabled on the jump host because ProxyJump needs it, and do not store private keys there. On servers that have no reason to accept forwarded agents, the SSH hardening guide recommends AllowAgentForwarding no. The manual cautions that this only helps if users are also denied shell access, since they can run their own forwarders. Combine it with a second factor from the two-factor guide, and read the key fingerprints in logs, as covered in the log analysis guide.

Related terms: SSH, Bastion host, sshd_config, Key-based authentication, Least privilege.