What's Actually Happening

Agent forwarding lets you use your local SSH keys on a remote server to connect to yet another server. When it doesn't work, you can't hop from server A to server B using your original keys.

The Error You'll See

On the remote server, when trying to connect to another host:

bash
user@serverA:~$ ssh user@serverB
Could not open a connection to your authentication agent

Or:

bash
user@serverA:~$ ssh-add -l
Could not open a connection to your authentication agent

Why This Happens

  1. 1.Agent forwarding not enabled in client - You didn't use -A or configure it
  2. 2.Agent not running locally - No ssh-agent to forward
  3. 3.AllowAgentForwarding no on server - Server prohibits forwarding
  4. 4.SSH_AUTH_SOCK not set - Environment variable missing
  5. 5.Screen/tmux breaking the socket - Terminal multiplexer issues

Step 1: Enable Agent Forwarding

Connect with the -A flag:

bash
ssh -A user@serverA

Or add to ~/.ssh/config:

bash
Host serverA.example.com
    ForwardAgent yes

Security warning: Only forward agent to trusted servers. A compromised server could use your keys while you're connected.

Step 2: Verify Local Agent is Running

On your local machine:

bash
ssh-add -l

You should see your keys listed. If you get "Could not open a connection to your authentication agent":

```bash # Start the agent eval "$(ssh-agent -s)"

# Add your keys ssh-add ~/.ssh/id_ed25519 ```

Step 3: Check Server Allows Forwarding

On the server:

bash
grep AllowAgentForwarding /etc/ssh/sshd_config

If it shows AllowAgentForwarding no or is commented out (defaults to yes), the server needs to allow it:

bash
sudo sed -i 's/#AllowAgentForwarding yes/AllowAgentForwarding yes/' /etc/ssh/sshd_config
# Or add it:
echo "AllowAgentForwarding yes" | sudo tee -a /etc/ssh/sshd_config
sudo systemctl restart sshd

Step 4: Check SSH_AUTH_SOCK on Remote Server

After connecting with -A:

bash
user@serverA:~$ echo $SSH_AUTH_SOCK
/tmp/ssh-XXXXXXXXXX/agent.12345

If it's empty, forwarding didn't work. Check the client side again.

Step 5: Handle Screen/Tmux Issues

If you're using screen or tmux on the remote server, the SSH_AUTH_SOCK may become stale. Fix this:

For tmux, add to ~/.tmux.conf:

bash
set -g update-environment "DISPLAY SSH_ASKPASS SSH_AUTH_SOCK SSH_AGENT_PID SSH_CONNECTION WINDOWID XAUTHORITY"

Or manually update when attaching:

bash
# Before attaching to tmux
export SSH_AUTH_SOCK=$(ls /tmp/ssh-*/agent.* 2>/dev/null | head -1)
tmux attach

Step 6: Test Agent Forwarding

```bash # From your local machine ssh -A user@serverA

# On serverA, check if forwarding works ssh-add -l

# You should see your local keys! # Now try to connect to serverB ssh user@serverB ```

Security Best Practices

  1. 1.Only forward to trusted servers - A malicious server can use your agent
  2. 2.Use -A only when needed - Don't add to all hosts in config
  3. 3.Consider SSH certificates - Alternative to agent forwarding
  4. 4.Use ProxyJump instead - Often cleaner than agent forwarding

ProxyJump Alternative

Instead of agent forwarding, use ProxyJump:

bash
ssh -J user@serverA user@serverB

Or in config:

bash
Host serverB
    ProxyJump user@serverA

This keeps your keys local and works without agent forwarding.

Verify the Fix

```bash # Connect with forwarding ssh -A user@serverA

# Check agent is accessible ssh-add -l

# Test a second hop ssh user@serverB "hostname" # Should return serverB's hostname ```