Password-less SSH not working with Mac OS X 10.9.5 Mavericks
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.
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
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.