Server does not accept public key for ssh login without password

Question

Possible Duplicate:
Why am I still getting a password prompt with ssh with public key authentication?

I have ssh access to two sever. One old one and one new one. For the old one I use the tutorial SSH login without password to login without typing the password every time.

For the new machine I followed the tutorial again, but this time it is not working. I looked at the debug output from ssh (-v option) and it seems to me that the new server does not accept my public key. But I checked and bot authorized_keys are the same, I even used md5sum.

What could be the problem and how could I fix this?

Debug output for old server where it does work (snippet):

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/NICK/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277

Debug output for new server where it does not work (snippet):

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/NICK/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/NICK/.ssh/id_dsa

[UPDATE] Ownership of authorized_keys on remote

NICK@server-new:~/.ssh$ ls -l
total 4
-rwx------ 1 NICK NICK 404 2012-08-08 16:11 authorized_keys

Complete debug output for the not working server:

OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /home/NICK/.ssh/config
debug1: /home/NICK/.ssh/config line 1: Applying options for foo2
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to foo-serv2.cs.bar.it [XXX.XXX.XXX.XXX] port 22.
debug1: Connection established.
debug1: identity file /home/NICK/.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/NICK/.ssh/id_rsa-cert type -1
debug1: identity file /home/NICK/.ssh/id_dsa type -1
debug1: identity file /home/NICK/.ssh/id_dsa-cert type -1
debug1: identity file /home/NICK/.ssh/id_ecdsa type -1
debug1: identity file /home/NICK/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 Debian-4ubuntu6
debug1: match: OpenSSH_5.5p1 Debian-4ubuntu6 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: 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 XXX
debug1: Host 'foo-serv2.cs.bar.it' is known and matches the RSA host key.
debug1: Found key in /home/NICK/.ssh/known_hosts:34
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,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/NICK/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/NICK/.ssh/id_dsa
debug1: Trying private key: /home/NICK/.ssh/id_ecdsa
debug1: Next authentication method: password

Did you make sure that the ownership and mode of your ~/.ssh directory on the remote side is correct? It should be owned by you, and have 0700 permissions. — jsbillings, Aug 08 '12 at 14:33
Thanks for your comment. I updated the permissions, but the error stayed the same. — Framester, Aug 08 '12 at 14:50
Four-oh-four error: -rwx------ 1 NICK NICK 404 2012-08-08 16:11 authorized_keys — Tim, Aug 08 '12 at 15:16
Keep in mind, I meant the permissions on the DIRECTORY and not the FILES in ~/.ssh. I meant you were to run chmod 700 ~/.ssh. — jsbillings, Aug 08 '12 at 15:34
Thanks @jsbillings, that was the solution! If you turn your comment into an answer, I will accept it. — Framester, Aug 08 '12 at 16:15
If you would have run sshd in debug-mode you would have seen the problem much faster... — Nils, Aug 08 '12 at 20:24
@Gilles, thanks, I did not find this question while searching. I flagged my question as duplicate. — Framester, Aug 09 '12 at 11:20

score 46 · Accepted Answer · edited Jun 04 '16 at 16:58

46

Did you make sure that the ownership and mode of your ~/.ssh directory on the remote side is correct? It should be owned by you, and have 0700 permissions, i.e. chmod 700 ~/.ssh. Also chmod go-w ~ as this is checked also - because anyone with write permission on your home directory can change the permissions of the .ssh directory.

edited Jun 04 '16 at 16:58

Jeff Schaller

67,283
35
116
255

answered Aug 08 '12 at 16:34

jsbillings

24,406

24

Apparently the home directory must be set to 700 as well (or less permissive than 777, anyway). – Tgr Nov 12 '12 at 07:39
Yes, 777 is a really bad mode to have your homedir. That means ANYONE on the system could add/remove/modify files in your homedir (at least, if it's just unix permissions restricting access) – jsbillings Nov 12 '12 at 20:44
7

In my case, my home directory was 775 and I saw this problem. Changing it to 755 fixed it for me. – Matt Connolly Aug 27 '13 at 10:50
7

755 of home directory works well for me. – xi.lin Sep 07 '15 at 06:36
1

@Tgr thank you good sir for resolving my vexing problem – Jon Deaton Aug 14 '17 at 04:47
2

Set the permission of the home directory as 740 in the server works for me. – Searene Oct 03 '17 at 10:07
@sbillings, you saved my life! – not2savvy Sep 27 '19 at 17:07
dis worked for me :thumbsup: – Rainb May 21 '20 at 09:15

score 6 · Answer 2 · answered Aug 08 '12 at 15:38

6

Compare the sshd configuration files (mine's at /etc/ssh/sshd_config) on the old and new server - is something set up differently on the new one, for example does the AuthorizedKeysFile option on the new one point to some other file (I believe some SSH installations nowadays call the file authorized_keys2)?

answered Aug 08 '12 at 15:38

Thanks for your input. I checked the files, but there were both identical. – Framester Aug 08 '12 at 16:15
Don't forget to restart your sshd service. Something like service sshd restart depending on OS – Adam Grant Feb 02 '17 at 02:56

Server does not accept public key for ssh login without password

2 Answers2