7

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

6
  • I am assuming root logins are allowed in your sshd_config?
    – heavyd
    Jun 21, 2010 at 14:53
  • Is this a problem specific to this server? Have you successfully set up ssh key authorization before? Jun 21, 2010 at 15:12
  • There are other accounts authenticating in this fashion just fine, just not root
    – Elle H
    Jun 21, 2010 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.
    – Elle H
    Jun 21, 2010 at 22:38
  • 1
    Check SSHD logs in my case I did rsync with -a option and by mistake I changed ownership of /root folder and that leads to not accepting my already trusted pubkey
    – Gelldur
    Sep 19, 2021 at 7:50

9 Answers 9

2

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

PubkeyAuthentication Yes
RSAAuthentication Yes
PermitRootLogin Yes
5
  • RSAAuthentication yes PubkeyAuthentication yes
    – Elle H
    Jun 21, 2010 at 14:47
  • Check if PermitRootLogin is not set to no, if it set to no set it to nopwd
    – radius
    Jun 21, 2010 at 14:53
  • 1
    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.
    – Elle H
    Jun 21, 2010 at 15:01
  • @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, 2012 at 15:37
  • 1
    -1 This solution do not work. Besides this contains a deprecated option.
    – Brethlosze
    Feb 12, 2019 at 5:22
13

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.

2
  • 1
    My logs showed nothing about denying access but I ran this command anyway. And what do you know, it worked. Thanks! Sep 9, 2013 at 10:43
  • Same as @Kaivosukeltaja, nothing in the logs, but the command works.
    – ushuz
    Dec 22, 2022 at 1:54
8

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:~$ 
3
  • Instead of disabling StrictModes you could fix the file permissions of files in .ssh (and the .ssh directory itself) instead.
    – Flimm
    Oct 28, 2015 at 13:46
  • @Flimm How?....
    – Brethlosze
    Feb 12, 2019 at 5:23
  • 3
    @Brethlosze chmod 0600 ~/.ssh/authorized_keys* and chmod 0700 ~/.ssh
    – Jellicle
    Oct 27, 2020 at 15:41
5

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.

2
  • 3
    /var/log/auth.log on the server, not the client (in case someone assumes the latter).
    – Daniel Beck
    Jul 2, 2012 at 5:49
  • And... how those permission should be fixed?
    – Brethlosze
    Feb 12, 2019 at 5:24
3

In case others run into the same problem I did, which took me an embarrassingly long time to figure out; always use ssh-copy-id where available to install your public key.

Call this from the client you are trying to configure for passwordless login, like so:

ssh-copy-id -i ~/.ssh/id_rsa.pub -p <port_number> <username>@<host>

Swapping port_number (if customised) and the username and host of the user you're trying to connect to on the remote host.

This will avoid any inconsistencies when copying across your public key by other means, as even a single incorrect or unexpected character will prevent login, and it's surprisingly easy to do it wrong!

2

I want to put forth my finding for future Googlers--I tried PermitRootLogin yes and context changing but none worked. Also, in CentOS 7 the correct log to look at seems to be tail -f /var/log/secure. There is no auth.log in my server.

Anyway, after looking at /var/log/secure, I realize the following line:

Jul 1 00:01:46 my-server sshd[113597]: Authentication refused: bad ownership or modes for file /home/minion/.ssh/authorized_keys

Motivated by that, after changing ~/.ssh to 0700 and authorized_keys to 0600, sshd server accepts my public key.

1

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.

1

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
....
0

In my case I had extended the permissions of the user's home dir such that its group also has write permissions (775 instead of the usual 755). Looking at /var/log/auth.log revealed the cause after many other attempts, as suggested by @Andy Zhang.

You must log in to answer this question.

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