0

I can ssh from hostA to hostB and from hostA to hostC using keys loaded into ssh-agent without any problems. However, if I do ssh -A hostB from hostA, then try ssh hostC from hostB, public key authentication doesn't work and it asks for my password.

Some details:

  • I am using ssh-agent that comes with OpenSSH, not GNOME Keyring or anything like that.
  • Both ssh -v hostB from hostA and ssh -v hostC from hostA show:

    debug1: Next authentication method: publickey
    debug1: Offering RSA public key: /home/rhansen/.ssh/id_rsa
    debug1: Server accepts key: pkalg ssh-rsa blen 279
    debug1: Authentication succeeded (publickey).
    
  • I see my key when I run ssh-add -L on hostB.

  • My key on hostA is protected with a password.
  • On hostB, /etc/ssh/sshd_config does NOT contain AllowAgentForwarding no.
  • All three systems run Ubuntu 15.10 (Wily) with OpenSSH 6.6.1p1.
  • When I run ssh -vvv hostC from hostB, the following is logged:

    ...
    debug2: key: /home/rhansen/.ssh/id_rsa ((nil)),
    debug2: key: /home/rhansen/.ssh/id_dsa ((nil)),
    debug2: key: /home/rhansen/.ssh/id_ecdsa ((nil)),
    debug2: key: /home/rhansen/.ssh/id_ed25519 ((nil)),
    debug1: Authentications that can continue: publickey,password
    debug3: start over, passed a different list publickey,password
    debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
    debug3: authmethod_lookup publickey
    debug3: remaining preferred: keyboard-interactive,password
    debug3: authmethod_is_enabled publickey
    debug1: Next authentication method: publickey
    debug1: Trying private key: /home/rhansen/.ssh/id_rsa
    debug3: no such identity: /home/rhansen/.ssh/id_rsa: No such file or directory
    debug1: Trying private key: /home/rhansen/.ssh/id_dsa
    debug3: no such identity: /home/rhansen/.ssh/id_dsa: No such file or directory
    debug1: Trying private key: /home/rhansen/.ssh/id_ecdsa
    debug3: no such identity: /home/rhansen/.ssh/id_ecdsa: No such file or directory
    debug1: Trying private key: /home/rhansen/.ssh/id_ed25519
    debug3: no such identity: /home/rhansen/.ssh/id_ed25519: No such file or directory
    debug2: we did not send a packet, disable method
    debug3: authmethod_lookup password
    debug3: remaining preferred: ,password
    debug3: authmethod_is_enabled password
    debug1: Next authentication method: password
    
  • If I do ssh -vvv hostB from hostA, then do ssh hostC, the following is logged by hostA just before the hostC password prompt:

    debug1: client_input_channel_open: ctype [email protected] rchan 2 win 65536 max 16384
    debug2: fd 10 setting O_NONBLOCK
    debug3: fd 10 is O_NONBLOCK
    debug1: channel 2: new [authentication agent connection]
    debug1: confirm [email protected]
    
  • My ~/.ssh/config on all systems contains the following uncommon settings (plus some common ones that I don't think are relevant):

    ControlMaster auto
    ProxyCommand sh ~/.ssh/proxy.sh '%h' '%p' '%r'
    IdentitiesOnly yes
    

Any ideas?

4
  • Which agent are you using on hostA – OpenSSH's default ssh-agent? GNOME Keyring? gpg-agent? Pageant? Mar 27, 2016 at 10:03
  • Also, anything special in hostB's ~/.ssh/config or /etc/ssh/ssh_config (the client one, not sshd_config)? Mar 27, 2016 at 10:04
  • Also, can you ssh -vv hostC from hostA to confirm that it's really the agent that provides the keys in the working direct connection? Mar 27, 2016 at 10:05
  • @grawity: I updated my question Mar 27, 2016 at 23:47

2 Answers 2

4

It turns out the culprit was the following line in my ~/.ssh/config:

IdentitiesOnly yes

I had added that a while back when I was experimenting with lots of keys that were causing "too many attempts" rejections. I forgot about it when I finished experimenting so I never removed it. (It had never caused any problems until I started using agent forwarding.)

0

I am glad to see that you were able to fix the issue on your own.

Your issue was different from the one I was having, but I will add the one I was having just in case someone comes across this post with the one I had.

In my case, the issue was that my home directory had permissions of 775, which ssh does not allow. Not only does the .ssh/ directory need to be 700, and the authorized_keys need to 600, but the home directory itself has to be 755 or below (e.g. 700).

0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .