I'm on OS X Yosemite 10.10.5, and my SSH client is behaving in a way I can't explain or resolve.

My goal is simply to connect to a server with:

ssh -A core@

When I add -v to this, I can see that my SSH client fails to try any key other than my ~/.ssh/id_rsa key. I've confirmed that ssh-agent is running, and used ssh-add -l to confirm the key I want is added.

Here's what I'm running in my local bash prompt:

# Run ssh-agent
bash-3.2$ eval $(ssh-agent)
Agent pid 7786

# Confirm it's running
bash-3.2$ sudo ps aux | grep ssh-agent
josh             7794   0.0  0.0  2432772    676 s000  S+    1:32PM   0:00.00 grep ssh-agent
josh             7786   0.0  0.0  2480640   2180   ??  Us    1:31PM   0:00.04 ssh-agent

# Login successfully by explicitly specifying a key
bash-3.2$ ssh -i sandbox core@
Last login: Tue Aug 18 20:13:31 2015 from X.Y.189.46
CoreOS stable (723.3.0)
core@ip-10-200-4-138 ~ $ exit
Connection to closed.

# Now attempt to connect using ssh-agent
bash-3.2$ ssh-add sandbox
Identity added: sandbox (sandbox)
bash-3.2$ ssh -A core@

# My just-added key isn't tried, so I'm prompted for a password
core@'s password:

Any help would be much appreciated!

Update: As requested, here's the verbose output:

bash-3.2$ ssh -v -A core@
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /Users/josh/.ssh/config
debug1: /Users/josh/.ssh/config line 1: Applying options for *
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 102: Applying options for *
debug1: Connecting to [] port 22.
debug1: Connection established.
debug1: identity file /Users/josh/.ssh/id_rsa type 1
debug1: identity file /Users/josh/.ssh/id_rsa-cert type -1
debug1: identity file /Users/josh/.ssh/id_dsa type -1
debug1: identity file /Users/josh/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7
debug1: match: OpenSSH_6.7 pat OpenSSH*
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-sha1-etm@openssh.com none
debug1: kex: client->server aes128-ctr hmac-sha1-etm@openssh.com none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<2048<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA a8:d9:fb:07:a6:71:de:99:76:9e:55:9c:bd:68:87:55
debug1: Host '' is known and matches the RSA host key.
debug1: Found key in /Users/josh/.ssh/known_hosts:164
debug1: ssh_rsa_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_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/josh/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /Users/josh/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
  • ssh-add -L should confirm if you have running agent and you have valid connection to it. – Jakuje Aug 18 '15 at 20:40
  • ssh-add -L outputs my public key file, so that seems to be working. – Josh Padnick Aug 18 '15 at 20:55
  • Verbose output of SSH command would help also – Jakuje Aug 18 '15 at 20:57
  • Have you tried running it with dstruss? – VaTo Aug 19 '15 at 4:43
  • @Josh Padnick Did you ever figure out what was causing this in your case? (I'm seeing the same thing on a freshly installed Ubuntu 18.04 box of mine) – Bjoern Dahlgren Apr 23 at 15:26

Is sandbox a version 1 or version 2 key? If it's an old key, it might only be working with version 1 of the ssh protocol. You can figure this out by running ssh -A -1 core@

  • Thx for the input. It does appear to be an old key (running the code returned Protocol major versions differ: 1 vs. 2), however one of my colleagues, also running OS X (10.10 in his case vs. 10.10.5 in my case) can successfully log in with ssh-agent and the exact same key. – Josh Padnick Aug 19 '15 at 19:38
  • Probably your colleague is defaulting to ssh version 1. This isn't necessarily advisable, but you can put Protocol 1,2 in the appropriate stanza of your ~/.ssh/config file (Below a line for Host Better would be to insert a version 2 key in the authorized_keys file on the server machine. – user3188445 Aug 20 '15 at 10:43

The verbose output shows that your keys are being offered. just not accepted. The most common problem here is permissions.

On the remote server, run:

ls -ld $HOME $HOME/.ssh $HOME/.ssh/authorized_keys

You will see output like this:

wwalker@serenity:~$ ls -ld $HOME $HOME/.ssh $HOME/.ssh/authorized_keys
drwx------. 66 wwalker wwalker 36864 2016-08-28 12:31:03.241 /home/wwalker
drwx------.  2 wwalker wwalker 32768 2016-08-28 11:57:52.282 /home/wwalker/.ssh
-rw-------.  1 wwalker wwalker  3182 2015-09-27 12:07:58.000 /home/wwalker/.ssh/authorized_keys

Fix whichever things have group or other write permissions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.