SSH Agent Forwarding
Last updated: April 2026
SSH agent forwarding allows you to use your local SSH private keys to authenticate to a second (or third) server through an intermediate host — without ever copying your private key to that intermediate host. The private key material never leaves your workstation; instead, authentication requests are forwarded back to your local SSH agent over the encrypted SSH channel.
When to Use Agent Forwarding
The most common use case is a bastion host (also called a jump host or jump box). In many network architectures, internal servers are not directly reachable from the internet or from your workstation. You first SSH into a bastion host in a DMZ, then SSH from there to internal targets.
Without agent forwarding, you would need to either:
- Copy your private key to the bastion host (a significant security risk — if the bastion is compromised, your key is exposed).
- Use password authentication for the second hop (less secure and harder to automate).
- Generate a separate key pair on the bastion and deploy its public key to all internal hosts (increases key management overhead).
Agent forwarding solves this cleanly. Your workstation holds the private key, and the bastion merely relays authentication challenges back to your local agent.
How It Works
- Your local SSH agent holds your private key(s) in memory.
- When you connect to the bastion with agent forwarding enabled, the SSH client creates a Unix domain socket (or named pipe on Windows) on the bastion that points back to your local agent.
- When you SSH from the bastion to an internal server, the internal server sends an authentication challenge.
- The bastion's SSH client forwards this challenge through the socket back to your local agent.
- Your local agent signs the challenge with your private key and sends the response back through the chain.
- The internal server verifies the signature and grants access.
At no point does the private key leave your workstation.
Setting Up the Windows SSH Agent
RockTerm integrates with the Windows OpenSSH Authentication Agent. Before using agent forwarding, ensure the agent is running and your keys are loaded.
Start the OpenSSH Authentication Agent Service
Open PowerShell as Administrator:
Get-Service ssh-agent | Select-Object Status, StartType
If the service is stopped or disabled:
Set-Service -Name ssh-agent -StartupType Automatic
Start-Service ssh-agent
Add Your Key to the Agent
ssh-add C:\Users\<username>\.ssh\id_ed25519
You will be prompted for the key's passphrase (if one is set). Once added, the agent holds the decrypted key in memory for the duration of the session.
Verify Loaded Keys
ssh-add -l
This lists the fingerprints of all keys currently held by the agent.
Enabling Agent Forwarding in RockTerm
- Open the connection profile for the bastion host.
- Navigate to Connection > SSH > Authentication.
- Check Enable agent forwarding.
- Ensure Authentication method is set to Agent (or Public Key with the agent integration enabled).
- Connect to the bastion. From there, SSH to internal hosts as usual — authentication challenges will be forwarded to your local agent automatically.
Verifying Agent Forwarding Is Active
Once connected to the bastion, run:
ssh-add -l
If agent forwarding is working, you will see your key fingerprint(s) listed — even though the key is not physically on the bastion. If you see "Could not open a connection to your authentication agent," forwarding is not active.
Also check that the SSH_AUTH_SOCK environment variable is set:
echo $SSH_AUTH_SOCK
It should point to a socket file (e.g., /tmp/ssh-XXXX/agent.PID).
Server-Side Requirements
Agent forwarding must be permitted by the SSH server on the bastion host. In /etc/ssh/sshd_config:
AllowAgentForwarding yes
This is the default on most distributions, but it may be explicitly disabled in hardened configurations. Restart sshd after changes.
Security Considerations
Agent forwarding is powerful but introduces a specific risk: anyone with root access on the intermediate host can use your forwarded agent to authenticate as you for as long as your session is active.
The Risk
When agent forwarding is enabled, the SSH server on the bastion creates a socket file. Any user with root privileges on the bastion can connect to this socket and issue signing requests to your agent — effectively impersonating you to any server that trusts your key. They cannot extract the private key itself, but they can use it to authenticate while your session is open.
Mitigations
- Only forward to trusted hosts. Never enable agent forwarding when connecting to servers you do not fully trust or control.
- Use jump host configuration instead. RockTerm's proxy/jump host feature (using
ProxyJump) is a safer alternative because it does not require agent forwarding — the SSH connection is tunneled through the bastion without exposing your agent. - Use key confirmation. If your SSH agent supports it, enable per-use confirmation so you are prompted each time the agent signs a challenge:
ssh-add -c ~/.ssh/id_ed25519. - Limit key lifetime in the agent. Add keys with a time limit:
ssh-add -t 3600 ~/.ssh/id_ed25519(key is available for 1 hour only). - Remove keys when done. After your session, clear the agent:
ssh-add -D.
Troubleshooting
Agent Forwarding Not Working
- Verify the Windows
ssh-agentservice is running and your key is loaded (ssh-add -l). - Confirm Enable agent forwarding is checked in the RockTerm connection profile.
- Confirm
AllowAgentForwarding yesin the bastion'ssshd_config. - Check that
SSH_AUTH_SOCKis set on the bastion after connecting.
"Could not open a connection to your authentication agent"
This message on the bastion means the agent socket was not created. Possible causes:
- Agent forwarding is disabled in the client configuration.
AllowAgentForwardingis set tonoon the bastion.- A
Matchblock insshd_configis overriding the global setting for your user.
Still need help?
If you're still experiencing issues, contact us or email info@rockriverresearch.com.