SSH Not Accepting Public Key

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 xxxxxx.com [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: SSH2_MSG_KEX_DH_GEX_REQUEST 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: 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_REQUEST sent

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

Zurahn

Posted 2010-06-21T14:37:27.810

Reputation: 782

I am assuming root logins are allowed in your sshd_config? – heavyd – 2010-06-21T14:53:21.103

Is this a problem specific to this server? Have you successfully set up ssh key authorization before? – Doug Harris – 2010-06-21T15:12:56.620

There are other accounts authenticating in this fashion just fine, just not root – Zurahn – 2010-06-21T15:13:45.650

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 – 2010-06-21T22:38:37.527

Answers

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

PubkeyAuthentication Yes
RSAAuthentication Yes
PermitRootLogin Yes

radius

Posted 2010-06-21T14:37:27.810

Reputation: 1 301

RSAAuthentication yes PubkeyAuthentication yes – Zurahn – 2010-06-21T14:47:06.750

Check if PermitRootLogin is not set to no, if it set to no set it to nopwd – radius – 2010-06-21T14:53:10.653

1It 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 – 2010-06-21T15:01:18.343

-1 This solution do not work. Besides this contains a deprecated option. – Brethlosze – 2019-02-12T05:22:28.600

@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 – 2012-05-19T15:37:00.003

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.

Pada

Posted 2010-06-21T14:37:27.810

Reputation: 193

My logs showed nothing about denying access but I ran this command anyway. And what do you know, it worked. Thanks! – Kaivosukeltaja – 2013-09-09T10:43:19.287

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 10.1.3.25
sysadmin@kaiser:~$ date
vie nov  9 17:53:11 CST 2012
sysadmin@kaiser:~$

derunbekanntschatten

Posted 2010-06-21T14:37:27.810

Reputation: 61

Instead of disabling StrictModes you could fix the file permissions of files in .ssh (and the .ssh directory itself) instead. – Flimm – 2015-10-28T13:46:22.547

@Flimm How?.... – Brethlosze – 2019-02-12T05:23:27.260

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.

pfrenssen

Posted 2010-06-21T14:37:27.810

Reputation: 481

In my case the issues was with the incorrect shell exec.

journalctl -f
....
Feb 25 11:45:54 59a02b89e0f6 sshd[]: User user not allowed because shell /usr/bin/env /bin/bash does not exist
....

Changed /etc/passwd file for that user

vi /etc/passwd 
....
user:x:1000:1000::/home/user:/bin/bash
....

nelaaro

Posted 2010-06-21T14:37:27.810

Reputation: 9 321

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.

Andy Zhang

Posted 2010-06-21T14:37:27.810

Reputation: 1

And... how those permission should be fixed? – Brethlosze – 2019-02-12T05:24:14.927

1/var/log/auth.log on the server, not the client (in case someone assumes the latter). – Daniel Beck – 2012-07-02T05:49:09.267