Take the 2-minute tour ×

When setting up ssh keys between two machines, the authentication only works one way. One server doesn't accept the public key of the other when trying to connect. Any ideas? Here's the verbose output.



debug1: Connecting to xxxxxx.com [xx.xx.xx.xx] port 22.

debug1: Connection established.





debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_3.6.1p2

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received




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: Host 'xxxxxx.com' is known and matches the RSA host key.

debug1: Found key in /root/.ssh/known_hosts:17

debug1: ssh_rsa_verify: signature correct

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug1: SSH2_MSG_NEWKEYS received


debug1: SSH2_MSG_SERVICE_ACCEPT received

debug1: Authentications that can continue: publickey,password

debug1: Next authentication method: publickey



debug1: Authentications that can continue: publickey,password


debug1: Next authentication method: password

EDIT: If it matters, this is for root

share|improve this question
I am assuming root logins are allowed in your sshd_config? –  heavyd Jun 21 '10 at 14:53
Is this a problem specific to this server? Have you successfully set up ssh key authorization before? –  Doug Harris Jun 21 '10 at 15:12
There are other accounts authenticating in this fashion just fine, just not root –  Zurahn Jun 21 '10 at 15:13
I ended up using a different account that was working and sudoing. Ok, not as elegant, but I'd spent enough time on this. –  Zurahn Jun 21 '10 at 22:38

5 Answers 5

up vote 1 down vote accepted

Check the values of the following options on the ssh server:

PubkeyAuthentication Yes
RSAAuthentication Yes
PermitRootLogin Yes
share|improve this answer
RSAAuthentication yes PubkeyAuthentication yes –  Zurahn Jun 21 '10 at 14:47
Check if PermitRootLogin is not set to no, if it set to no set it to nopwd –  radius Jun 21 '10 at 14:53
It was set to yes and I changed it to without-password and restarted ssh without any effect whatsoever -- it still asked for a password. That, my friend, is determination. –  Zurahn Jun 21 '10 at 15:01
@Zurahn: then why did you mark the answer accepted? –  Tobias Kienzler Dec 14 '10 at 9:05
@radius there is no nopwd. And setting it to without-password is only making it a bit more secure, in that they'd still need a key. And anyhow keys come first anyway. If he can't get in with a key, he still won't be able to get in with a key. I don't know, maybe he hadn't copied his public key over, or maybe he wasn't logging in as the right user on the ssh server. –  barlop May 19 '12 at 15:37

I've just had a case where SELinux prevented sshd from reading the /root/.ssh/authorized_keys file. /var/log/messages will show you that the sshd process was denied access for read operation on the authorized_keys file.

After I ran restorecon -v /root/.ssh/authorized_keys, SSH with the public-key worked fine.

share|improve this answer
My logs showed nothing about denying access but I ran this command anyway. And what do you know, it worked. Thanks! –  Kaivosukeltaja Sep 9 '13 at 10:43

Changing StrictModes to "no" in /etc/ssh/sshd_config worked for me.

sysadmin@suselinux1:~> con sysadmin kaiser
Welcome to Ubuntu 12.04.1 LTS (GNU/Linux 3.2.0-25-generic i686)

 * Documentation:  https://help.ubuntu.com/

Last login: Fri Nov  9 15:40:11 2012 from
sysadmin@kaiser:~$ date
vie nov  9 17:53:11 CST 2012
share|improve this answer

Check the permission and owner of the .ssh folder, authorized_key file and the home folder, the /var/log/auth.log will give you more messages when you try to login.

share|improve this answer
/var/log/auth.log on the server, not the client (in case someone assumes the latter). –  Daniel Beck Jul 2 '12 at 5:49

My key was not being forwarded, turned out I had started the SSH agent in a different terminal window, so the $SSH_AUTH_SOCK environment variable was not available in the terminal in which I was making the connection.

So if you are starting the agent manually, make sure you make the connection in the same terminal session.

share|improve this answer

Your Answer


