Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have two Ubuntu Server machines sitting at home. One is (we'll call this 15), and the other is (we'll call this 25). For some reason, when I want to setup passwordless login from 15 to 25, it works like a champ. When I repeat the steps on 25, so that 25 can login without a password on 15, no dice. I have checked both sshd_config files. Both have:

RSAAuthentication yes
PubkeyAuthentication yes

I have checked permissions on both servers:

drwx------ 2 bion2 bion2  4096 Dec  4 12:51 .ssh
-rw------- 1 bion2 bion2  398 Dec  4 13:10 authorized_keys

On 25.

drwx------  2 shimdidly shimdidly  4096 Dec  4 19:15 .ssh
-rw-------  1 shimdidly shimdidly 1018 Dec  4 18:54 authorized_keys

On 15.

I just don't understand when things would work one way and not the other. I know it's probably something obvious just staring me in the face, but for the life of me, I can't figure out what is going on. Here's what ssh -v says when I try to ssh from 25 to 15:

ssh -v -p 51337
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 [] port 51337.
debug1: Connection established.
debug1: identity file /home/shimdidly/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/shimdidly/.ssh/id_rsa-cert type -1
debug1: identity file /home/shimdidly/.ssh/id_dsa type 2
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: identity file /home/shimdidly/.ssh/id_dsa-cert type -1
debug1: identity file /home/shimdidly/.ssh/id_ecdsa type -1
debug1: identity file /home/shimdidly/.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 54:5c:60:80:74:ab:ab:31:36:a1:d3:9b:db:31:2a:ee
debug1: Host '[]:51337' is known and matches the ECDSA host key.
debug1: Found key in /home/shimdidly/.ssh/known_hosts:2
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_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/shimdidly/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Offering DSA public key: /home/shimdidly/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/shimdidly/.ssh/id_ecdsa
debug1: Next authentication method: password
share|improve this question

migrated from Dec 5 '12 at 10:29

This question came from our site for professional and enthusiast programmers.

The two authorized_keys files have different sizes. Have you verified that they both contain the correct public key for the private key you are using to login? – Ex Umbris Dec 5 '12 at 4:31

You may need to have your public key in ~/.ssh/authorized_keys2 instead of ~/authorized_keys.

I don't know the exact order and conditions governing the use of those files offhand, but if you've got your sshd set to accept ssh2 auth only then it may only respect keys in .ssh/authorized_keys2.

share|improve this answer

It is important to check the permissions all the way up the path. If any directory along the path is group or world writable, you can't guarantee the directory is the one you intended.

share|improve this answer

I figured it out. I don't know why this is the case, but it wouldn't work until I moved ~/.ssh/authorized_keys outside of my home directory to /etc/ssh/username/authorized_keys as was suggested here under troubleshooting: . It also suggested that permissions should be as follows: 755 for the directory, and 644 for the authorized_keys file.

share|improve this answer
Sounds like you had too relaxed permissions on your .ssh directory. – tripleee Dec 5 '12 at 5:35
755 is more liberal than 700. – Nelson Dec 5 '12 at 6:12

You must log in to answer this question.