Why SSH Agent Forwarding Fails and How Resetting the Master Connection Fixes It

Introduction

SSH agent forwarding lets a developer use local private keys when connecting through intermediate servers, such as a Git repository, without copying keys to the remote host. Occasionally the error Could not open a connection to your authentication agent appears even though the configuration looks correct.

Configuration Review

Local client : The ~/.ssh/config file contains a host entry for gitlab-runner with ForwardAgent yes and other settings.

Host gitlab-runner
    Hostname i-072fd6721a00f4b42
    ProxyCommand aws ssm start-session ...
    User dave
    IdentityFile ~/.ssh/id_ec2
    ForwardAgent yes
    ...

The ForwardAgent yes line explicitly enables agent forwarding.

Running ssh-add -l shows a loaded key, confirming the local agent is ready:

daveking@192 personal % ssh-add -l
256 SHA256:bPvs3l3EcWZup7NFtZ/KiOCdTyBSKknl+xwXt4ybFG8 [email protected] (ED25519)

Remote server : The SSH daemon configuration includes AllowAgentForwarding yes, verified with:

dave@gitlab-runner:~$ grep Allow /etc/ssh/sshd_config.d/60-cloudimg-settings.conf
AllowAgentForwarding yes

Both sides appear correctly configured, yet the forwarding still fails.

Root Cause: Connection Multiplexing

Inspecting the verbose SSH output ( ssh -vvv) reveals a line such as:

debug1: auto-mux: Trying existing master at '/Users/daveking/.ssh/sockets/dave@i-072fd6721a00f4b42:22'

This indicates SSH is reusing an existing master connection (the “auto‑mux” feature). The first time a connection to gitlab-runner was made, the master session was created without ForwardAgent enabled. Subsequent connections inherit the settings of that original master, so even after updating the config, the agent is still not forwarded.

Solution: Reset the Master Connection

Close the stale master connection and start a fresh one that respects the current configuration.

Close the existing master connection

ssh -O exit gitlab-runner

The -O exit option tells SSH to terminate the master for the specified host.

Confirm the local agent still holds the key

ssh-add -l

Create a new connection

ssh gitlab-runner

Because the current ~/.ssh/config includes ForwardAgent yes and the agent has a loaded key, this new master will forward the agent correctly.

Verify on the remote server

dave@gitlab-runner:~$ ssh-add -l
256 SHA256:bPvs3l3EcWZup7NFtZ/KiOCdTyBSKknl+xwXt4ybFG8 [email protected] (ED25519)

The key appears on the remote side, confirming successful forwarding.

Conclusion

SSH offers powerful features like agent forwarding and connection multiplexing, but the latter can cause unexpected behavior when configuration changes are made after a master connection has been established. Resetting the master connection ensures new settings take effect, allowing reliable and secure forwarding.