ssh-agent and forwarding - keeping keys safe · Linux

ssh-agent holds decrypted private keys in memory, so you do not have to type the passphrase for every connection. Agent forwarding lets a remote host use your agent to authenticate further. Both have security trade-offs.

Start ssh-agent

eval $(ssh-agent -s)

Or use the systemd user service (modern):

systemctl --user enable --now ssh-agent
systemctl --user status ssh-agent

The systemd service exposes the agent socket at a fixed path and is shared across login sessions.

Add keys

ssh-add ~/.ssh/id_ed25519

Prompts for the passphrase (once). Subsequent ssh commands within the agent’s lifetime use the cached key.

ssh-add -l                   # list loaded keys
ssh-add -D                   # remove all keys
ssh-add -t 3600 ~/.ssh/key   # cache for 3600 seconds

Use the agent

Once keys are loaded, ssh uses them automatically:

ssh user@server    # no passphrase prompt

The agent is automatically consulted by ssh. The SSH_AUTH_SOCK environment variable tells ssh where to find the agent socket.

Forward the agent

By default, an SSH session on server A cannot reach your local agent. To enable agent forwarding:

ssh -A user@server

Or in ~/.ssh/config:

Host server
    ForwardAgent yes

The remote session can now use your keys to authenticate to other hosts:

user@server:~$ ssh user@anotherserver
# No passphrase prompt - uses your forwarded agent

The security problem with agent forwarding

When you forward your agent, the remote host can ask your agent to sign things on your behalf. If the remote host is compromised, an attacker can:

Use your keys to authenticate to other hosts you have access to.
Read any file the keys protect (with appropriate tooling).

This is a real risk. The 2018 GitHub incident involved an attacker using a forwarded agent to pivot.

Mitigations:

Do not forward agents by default. Use ForwardAgent no in your config.
Forward only to specific hosts that you trust completely.
Use ProxyJump instead of agent forwarding for the common “ssh through a bastion” pattern.
Use short-lived certificates instead of long-lived keys.

ssh-agent restrictions

Limit what a forwarded agent can do:

# ~/.ssh/authorized_keys on the target host
restrict,from="10.0.0.0/24",command="git-upload-pack",expiry-time=... ssh-ed25519 AAAAC3...

The restrict keyword enables all restrictions; you then selectively enable what the key can do.

Forward to specific socket

Forward the agent to a specific path on the remote:

ssh -R /tmp/agent.sock:$(echo $SSH_AUTH_SOCK) user@server

Use cases include making the agent accessible to a non-interactive service on the remote.

Hardware tokens (YubiKey, etc.)

For higher security, store private keys on a hardware token:

ssh-keygen -t ed25519-sk -O resident    # generate key on YubiKey
ssh-add -K                              # add the resident key

The private key never leaves the hardware. Even if the host is compromised, the attacker cannot extract the key.