Use it with caution. OpenSSH defaults ForwardAgent to no and warns that anyone who can bypass file permissions on the remote host can use your forwarded agent. They cannot copy your key, but they can authenticate as you while you are connected. Prefer ProxyJump or per-server keys.
What agent forwarding does
Normally your private key stays on your laptop and the SSH client signs challenges locally. With agent forwarding, the connection carries a channel back to your local ssh-agent, so programs on the remote server can ask your agent to sign things. That is how people run git pull on a server using their laptop key without copying the key there.
What the manual warns
The ssh_config manual says ForwardAgent accepts yes, no (the default), an explicit path to an agent socket, or the name of an environment variable holding the path. It then warns that forwarding should be enabled with caution.
The reason is specific. Users with the ability to bypass file permissions on the remote host, for the agent's Unix-domain socket, can access your local agent through the forwarded connection. The manual adds that an attacker cannot obtain key material from the agent, but can perform operations on the keys that let them authenticate using the identities loaded in the agent.
In plain words: the key is not stolen, but it can be used. On a shared or compromised server, that means a root user could reach any other system your key opens, for as long as your session is up.
Safer alternatives
| Need | Option |
|---|---|
| Reach an internal host through a jump host | ProxyJump, so the jump host only relays traffic |
| A server must pull from a Git host | A deploy key for that repository, or a short-lived token |
| Interactive work on a trusted box you own | Forwarding limited to that host in your config |
| Higher assurance | Keys held on a hardware token that needs a touch |
Never put ForwardAgent yes under Host *. Scope it to named hosts you control, and leave the default of no everywhere else.
A config you can adopt
Host build-box
ForwardAgent yes
Host *
ForwardAgent no
Order matters in an SSH config, since the first value found for an option wins, so put specific hosts above the wildcard. Review your file once a quarter and remove hosts you no longer use.
When you cannot avoid it
Load only the keys you need into the agent, and remove them when finished. Prefer an agent setup that asks for confirmation on each use, or a hardware key that needs a touch, so a silent signing request stands out. Treat any server where others have root as untrusted for forwarding purposes.
Where Safeguard fits
Safeguard works on the dependency and code side of your software: SBOM and dependency scanning, reachability analysis and policy gates. It does not store or manage credentials, so keep using your password manager, secrets manager or cloud identity for that. You can run a free scan of a project at gold.safeguard.sh/scan.
Quick check
Can an attacker steal my private key through forwarding?
The manual says they cannot obtain key material from the agent, but they can use the loaded identities to authenticate while the connection is live.
What is the default for ForwardAgent?
No, per the ssh_config manual.
Is ProxyJump the same thing?
No. It routes your connection through a jump host without giving that host access to your agent.
Sources
Last reviewed: 19 October 2026.
