Why is ssh agent forwarding not working?

Question

In my own computer, running MacOSX, I have this in ~/.ssh/config

Host *
ForwardAgent yes
Host b1
ForwardAgent yes

b1 is a virtual machine running Ubuntu 12.04. I ssh to it like this:

ssh pupeno@b1

and I get logged in without being asked for a password because I already copied my public key. Due to forwarding, I should be able to ssh to pupeno@b1 from b1 and it should work, without asking me for a password, but it doesn't. It asks me for a password.

What am I missing?

This is the verbose output of the second ssh:

pupeno@b1:~$ ssh -v pupeno@b1
OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to b1 [127.0.1.1] port 22.
debug1: Connection established.
debug1: identity file /home/pupeno/.ssh/id_rsa type -1
debug1: identity file /home/pupeno/.ssh/id_rsa-cert type -1
debug1: identity file /home/pupeno/.ssh/id_dsa type -1
debug1: identity file /home/pupeno/.ssh/id_dsa-cert type -1
debug1: identity file /home/pupeno/.ssh/id_ecdsa type -1
debug1: identity file /home/pupeno/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 35:c0:7f:24:43:06:df:a0:bc:a7:34:4b:da:ff:66:eb
debug1: Host 'b1' is known and matches the ECDSA host key.
debug1: Found key in /home/pupeno/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/pupeno/.ssh/id_rsa
debug1: Trying private key: /home/pupeno/.ssh/id_dsa
debug1: Trying private key: /home/pupeno/.ssh/id_ecdsa
debug1: Next authentication method: password
pupeno@b1's password:

score 121 · Accepted Answer · edited Oct 05 '19 at 07:35

121

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

edited Oct 05 '19 at 07:35

Community

1

answered Jul 03 '12 at 16:48

Pablo Fernandez

7,498

6

Note that ssh-add -K is specific to OS X. – Roger Lipscombe Sep 07 '16 at 10:29
3

Do you have to do this at every reboot? – tread Sep 12 '19 at 09:01
You executed ssh-add -k in your own computer or in the server (b1)? – a06e Oct 20 '21 at 14:01
1

Not only is ssh-add -K specific to MacOS, as @RogerLipscombe points out, but it also has security implications that may or may not be desirable. In particular, with -K, "When adding identities, each passphrase will also be stored in your keychain" -- meaning one would never again be asked for the key-specific passphrase, instead only needing (MacOS) keychain access. YMMV, but this is not what I would want. The -k option is not as problematic, but probably isn't necessary. A simple ssh-add (perhaps with a -t time, too) would probably do, assuming an agent is running. – lindes Dec 12 '21 at 03:59
as of 2023, running ssh-add -K on MacOS 12 Monterey gives a warning. WARNING: The -K and -A flags are deprecated and have been replaced by the --apple-use-keychain and --apple-load-keychain flags, respectively. run ssh-add --apple-load-keychain instead. – taiyodayo Mar 25 '23 at 17:16

W.Mann · Answer 2 · 2017-08-16T07:07:28.783

16

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.

edited Aug 16 '17 at 07:07

answered Aug 14 '17 at 18:43

W.Mann

261

3

YES! Some may not remember that they have ControlMaster set in their config. If master is active and you make a new connection with agent forwarding it will not work. Assuming you are a careful user who want the agent forward for a short period of time use -ASnone instead of the -A (or ControlPath none in config) – nhed Sep 29 '20 at 22:26

score 8 · Answer 3 · edited Oct 01 '20 at 16:21

8

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.
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.
Check if you have ssh-agent running, try to load keys via ssh-add
Try GSSAPI-based authentication and forwarding with ssh -K

edited Oct 01 '20 at 16:21

nhed

600

answered Jul 03 '12 at 16:41

Daniel Prata Almeida

702

The permission of the keys are fine and the key in authorized_keys is fine (otherwise I think I would have trouble connecting on the first place). – Pablo Fernandez Jul 03 '12 at 16:44
Did you have ssh-agent running? What happens when you do an ssh-add then ssh -A pupeno@b1 and then ssh pupeno@b1 ? – Daniel Prata Almeida Jul 03 '12 at 16:47
Why don't you update the answer to mention ssh-add -K and I'll accept yours instead of mine (since the information was posted almost simultaneously). – Pablo Fernandez Jul 03 '12 at 16:50
The remote .ssh/authorized_keys and .ssh folder must also have correct permissions. Also a symlink to a file with correct permissions may not be accepted. This can fail silently in some OpenSSH versions. – HKOB Nov 02 '22 at 15:30

score 8 · Answer 4 · answered May 22 '15 at 11:02

8

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

answered May 22 '15 at 11:02

BartBiczBoży

213

2

I had the same issue, only the permissions were wrong on /tmp. THANKS!! – nevyn Sep 04 '15 at 01:37

score 7 · Answer 5 · edited Oct 16 '20 at 06:34

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:

No agent forwarding

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):

Added ssh-agent to host

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:

Successfully forwarding ssh key

I'm sorry - I don't have the reputation on StackExchange to post the images inline, but it would be a better post if they were (help a fella out?) — farmer-Bri, Oct 16 '20 at 03:16
Thank you! I had made the same assumption about the agent and was making the host spawn and connect to an SSH agent for convenience. Now I'm making sure the user is not connected through SSH before starting the agent. Sometimes I feel like SSH couldn't be more confusing. — TheMechanic, Nov 13 '23 at 21:28

score 4 · Answer 6 · answered Jul 18 '16 at 20:22

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.

score 2 · Answer 7 · answered Sep 01 '20 at 18:03

2

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

answered Sep 01 '20 at 18:03

Vincent Yin

144
5

Daniel A.A. Pelsmaeker · Answer 8 · 2023-01-13T19:30:00.517

2

I had disabled agent forwarding for all hosts, thinking I could enable it for each specific host where I need it. Apparently that doesn't work.

Host *
  ForwardAgent no
Host myserver
  HostName myserver.example.nl
  ForwardAgent yes

The solution was to remove the ForwardAgent no from the Host * block.

edited Jan 13 '23 at 19:30

answered Sep 17 '21 at 11:47

Daniel A.A. Pelsmaeker

193

That was the most helpful tip for me. I also thought that the specific host entry would override the global setting. But that doesn't seem to be the case. It would be handy to have things like ForwardAgent turned off by default and only turned on for some individual use cases. But obviously this cannot be done within one configuration file. – Kellerspeicher Mar 20 '23 at 09:12

score 1 · Answer 9 · answered Nov 12 '20 at 17:41

1

Every SSH daemon must have:

AllowAgentForwarding yes

answered Nov 12 '20 at 17:41

Antonio Bardazzi

311

even if you specify ForwardAgent yes in your config? – Nesha25 Jun 25 '23 at 16:42
1

ForwardAgent is a client option indeed you can find it in man ssh_config but not in man sshd_config – Antonio Bardazzi Jun 27 '23 at 13:57

score 1 · Answer 10 · answered Aug 17 '16 at 01:39

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 git@github.com

Run ls remote test against targeted git repository

git ls-remote --heads git@github.com:**account**/**repo**.git

score 0 · Answer 11 · answered May 22 '20 at 22:30

0

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.

answered May 22 '20 at 22:30

Pierz

663

Why is ssh agent forwarding not working?

11 Answers11