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

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: Reading configuration data /usr/local/etc/ssh_config

debug1: Rhosts Authentication disabled, originating port will not be trusted.

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

debug1: Connection established.

debug1: identity file /root/.ssh/identity type -1

debug1: identity file /root/.ssh/id_rsa type 1

debug1: identity file /root/.ssh/id_dsa type -1

debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5

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: kex: server->client aes128-cbc hmac-md5 none

debug1: kex: client->server aes128-cbc hmac-md5 none


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 '' 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: Trying private key: /root/.ssh/identity

debug1: Offering public key: /root/.ssh/id_rsa

debug1: Authentications that can continue: publickey,password

debug1: Trying private key: /root/.ssh/id_dsa

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
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:

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
Instead of disabling StrictModes you could fix the file permissions of files in .ssh (and the .ssh directory itself) instead. – Flimm Oct 28 '15 at 13:46

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .