Why is ssh agent forwarding not working?

It turns out my key was not in the agent, and this fixed it:

OS X:

ssh-add -K

Linux/Unix:

ssh-add -k

You can list loaded keys using:

ssh-add -l

ssh-add -L # for more detail

Another possible reason is connection sharing: one might already be logged in on the other host without agent forwarding and connection sharing enabled. The second login with ssh -A (or equivalently specified in the config file) via the shared connection will silently ignore the -A flag. Only after completely logging out or disabling connection sharing for second login, the agent forwarding will work.

1. Check if your ~/.ssh/id_rsa ~/.ssh/id_dsa ~/.ssh/id_ecdsa files have the correct permissions which should be owned by your user and be chmoded 600.

2. Check that you have the correct public key on pupeno/.ssh/authorized_keys on b1, and check if authorized_keys has a line break at the end of the key.

3. Check if you have ssh-agent running, try to load keys via ssh-add

4. Try GSSAPI-based authentication and forwarding with ssh -K

I had problem with sshd server rejecting agent forwarding request because of no space left in /tmp. This was because sshd needs to create socket in /tmp. Cleaning disk up resolved my issue.

ssh -v said back then:

debug1: Remote: Agent forwarding disabled: mkdtemp() failed: No space left on device

For the benefit of other googlers who also arrived at this question:

Incorrect whitespace in a ~/.ssh/config file can also cause some head scratching.

I recently helped out one of my co-workers who had this:

# incorrect
host foobar ForwardAgent yes

instead of this:

# correct
host foobar
  ForwardAgent yes

I've also run into instances where missing indentation of the directives under the list of hosts made a difference to functionality, even though it's not supposed to.

For me, it was simply that the host I was connecting to (b1 in the original poster's example) was running it's own persistent ssh-agent. There's no debug output I could see to explain what was happening, the host just silently uses it's existing ssh-agent and no forwarding occurs. This makes sense to me in retrospect :p

The forwarding is like ssh port-forwarding: it's tunnelling, not client-server negotiation.

I assumed it was the latter - that having an ssh-agent running on the host would be necessary for agent forwarding, so I set it up at the beginning, but that was a mistake.

See the following examples:

First I ssh to host ccam (a raspberry pi) with no Agent Forwarding and confirm there's no agent socket or added keys:

Secondly I edit .bashrc to ensure ssh-agent is running on the host (this was my mistake). You can see when I reconnect using -A to enable Agent Forwarding, the agent socket exists, but the agent has no identities (I now realise that is because this is showing the local ssh-agent socket rather than a forwarded one):

Finally, I remove the ssh-agent on the raspberry-pi host (not shown) and reconnect. You can see the key is finally available when inspecting using ssh-add -L:

Add following lines to .ssh/config file

  Host **Server_Address**
     ForwardAgent yes

Add key to SSH Agent

 ssh-add -K

Connect to Remote Server

ssh -v **username**@**Server_Address**

Run connection test against GitHub

ssh -T [email protected]

Run ls remote test against targeted git repository

git ls-remote --heads [email protected]:**account**/**repo**.git

Yet another cause: If the target host's fingerprint doesn't match with your ~/.ssh/known_hosts, SSH automatically disables Agent Forwarding.

The solution is:

$ ssh -A -o UserKnownHostsFile=/dev/null  my-target-host

Every SSH daemon must have:

AllowAgentForwarding yes

If you're connecting to a machine running byobu/tmux it seems that sometimes you need to create a new window on the destination machine (e.g. Ctrl-B + C) after you connect with ssh -A so that you can use your ssh agent for onward authentication.