Password-less SSH not working with Mac OS X 10.9.5 Mavericks

Question

I cannot get password-less logins working on my Mac OS X 10.9.5 Mavericks machine. I can login to a remote Ubuntu box after setting up the authorized_keys file properly. However, I cannot do there reverse.

So I tried to troubleshoot the Mac setup by figuring out if I can do this without a password:

ssh localhost

Doing that on my Ubuntu box works well, but the Mac keeps asking for passwords. Yes I checked the authorized_keys file as well as the known_hosts file and made sure the id_rsa.pub key was present in both of them for my Mac. But I cannot SSH to localhost without a password.

I read the other posts such as this one.

And even enabled the following two settings(by deleting the hashtag in front of them) in the sshd_config file:

RSAAuthentication yes
PubKeyAuthentication yes

Still getting asked for the password.

Put copies of the authorized_key and known_hosts files in the etc directory.

Still getting asked for the password.

Solution 1

I provided an answer on Stack Overflow that explains the step-by-step process needed to set up password-less access via SSH. Here are those instructions adapted for your specific needs.

First, set the SSH connection into verbose mode by using the -v flag like this:

ssh -v localhost

As explained in the ssh man page; accessible via man ssh:

 -v      Verbose mode.  Causes ssh to print debugging messages about its
         progress.  This is helpful in debugging connection, authentica-
         tion, and configuration problems.  Multiple -v options increase
         the verbosity.  The maximum is 3.

This has saved me a lot of headaches in the past by showing me exactly how the login process is flowing & what exactly is clogging it up. For example, here is the output of me running that command on my local Mac OS X 10.9.5 machine:

ssh -v localhost

OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug1: Connecting to localhost [::1] port 22.
debug1: Connection established.
debug1: identity file /Users/JakeGould/.ssh/id_rsa type 1
debug1: identity file /Users/JakeGould/.ssh/id_rsa-cert type -1
debug1: identity file /Users/JakeGould/.ssh/id_dsa type -1
debug1: identity file /Users/JakeGould/.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.2
debug1: match: OpenSSH_6.2 pat OpenSSH*
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr [email protected] none
debug1: kex: client->server aes128-ctr [email protected] none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<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 01:aa:8e:8e:b9:e1:4b:e8:bd:c5:a2:20:a3:c7:f1:18
debug1: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /Users/JakeGould/.ssh/known_hosts:43
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_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/JakeGould/.ssh/id_rsa
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Trying private key: /Users/JakeGould/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
Password:

As you can see, it gets up the password prompt. But prior to that it is clearly checking for my RSA public key. And since I don’t have one, it just rolls over to the next authentication method. Pay attention to the output of ssh -v when you run it on your set to see where things get choked.

Also be sure the SSH files on the destination machine have permissions that match the following & are owned by the account trying to access like this example shows:

-rw------- [username] [usergroup] authorized_keys
-rw------- [username] [usergroup] id_rsa
-rw-r--r-- [username] [usergroup] id_rsa.pub
-rw-r--r-- [username] [usergroup] known_hosts

So run this command to chmod the authorized_keys file:

sudo chmod 600 ~/.ssh/authorized_keys

And run this command to chmod the id_rsa file:

sudo chmod 600 ~/.ssh/id_rsa

Solution 2

I found the problem. The remote host logs the origin of each RSA or DSA key. This is seen in plain text at the end of each line in the authorized keys list (which you usually cannot see because nano does not text wrap).

I was ssh'ing first to the remote host, then copying the key and merging it with authorized_keys. Bad.

From the client machine,the key has to be copied to the remote host with that special copy command, scp, or ssh-copy-id (OS X does not have this one unless installed with brew or port).

Then the merge to authorized_keys can be performed. Careless human error on my part.

Comments

[Giacomo1968]

What is the output of the ssh session when you do ssh -v localhost? That should tell you what it might be choking on.

[barlop]

maybe try stopping and starting the sshd service if you haven't already

[Paul]

90% of the time it is permissions.

[aquagremlin]

thank you for a thorough answer but i am still flummoxed. my ssh -v output is the same as yours (except for obvious differences like machine name and ssh key). Even though I do have an rsa private and public key pair and i successfully entered them into 'authorized_keys'. I also even did this: <br> ssh-keygen -t dsa -P '' -f ~/.ssh/id_dsa</br> <br>cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys'</br> but i still get the password prompt. next i'll just delete the account and start over.

[aquagremlin]

I deleted all my keys from .ssh folder and started over. SAME PROBLEM exists.

[aquagremlin]

I created a new account and now everything works. The only thing I did differently was to use a long password when creating the account (>3 letters. I used a short password initially because this was just a 'test' account)

[aquagremlin]

Well, I tried a THIRD time and again with a really short pw think none of this makes sense. And now it works. So bizarre. Thank you for trying to help me. I have no idea why these other accounts behaved badly. I will leave them in place so that I can troubleshoot them when I learn more.

[Giacomo1968]

@aquagremlin I am happy to have helped! If my answer was helpful to you please remember to up vote it. And if it is the answer that solved your problems, please check it off as such. Thanks!

[tresf]

Suffered a copy/paste error as well. Was able to circumvent it using cat locally and nano on the server. Upvoting because sometimes retrying the trivial is the best way to fix a problem.

[Admin]

"Then the merge to authorized_keys can be performed". facepalm I thought it was a directory! Problem solved :)