SSH using public keys is not working

Question

I have a system that is attempting to ssh to my using ssh [email protected] . They have sent me the public RSA key and I've installed it into my .ssh/authorized keys file. When they attempt to connect however, they see "Permission Denied".

In the secure log on my server, I see that a matching key was found, but it still denies access.

Any ideas?

Update:

In my haste to post this at the end of the day yesterday, I left out some important details.

First, and most importantly, multiple entities are using this same user on my side for login. This is a automated file repository and when someone wants to connect we have them send us the public key for their user and server, and I add it to the authorized_keys file for the user on my side. It's a non-root user. We have other outside parties who are able to successfully login using ssh. Its just this new user on the remote side isn't working.

The log shows:

Sep  1 15:24:56 SavFTPDNS sshd[31674]: Connection from X.X.X.X port 12857
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: Client protocol version 2.0; client software version OpenSSH_4.0
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: match: OpenSSH_4.0 pat OpenSSH*
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: Enabling compatibility mode for protocol 2.0
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: Local version string SSH-2.0-OpenSSH_4.2
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: PAM: initializing for "userA"
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: PAM: setting PAM_RHOST to "X.X.X.X"
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: PAM: setting PAM_TTY to "ssh"
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: temporarily_use_uid: 504/100 (e=0/0)
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: trying public key file /home/userA/.ssh/authorized_keys
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: matching key found: file /home/userA/.ssh/authorized_keys, line 18
Sep  1 15:24:56 SavFTPDNS sshd[31674]: Found matching RSA key: d2:4f:5e:cb:cf:78:a4:67:19:99:b8:7b:2a:71:9e:61
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: restore_uid: 0/0
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: temporarily_use_uid: 504/100 (e=0/0)
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: trying public key file /home/userA/.ssh/authorized_keys
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: restore_uid: 0/0
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: temporarily_use_uid: 504/100 (e=0/0)
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: trying public key file /home/userA/.ssh/authorized_keys2
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: restore_uid: 0/0
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: do_cleanup
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: PAM: cleanup

Answer 1

If you could copy/paste the lines from your log that you saw, that would help. A few guesses in the mean time:

Make sure that your permissions are correct.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

If you're trying to authenticate as root, you might need the following in your sshd_config:

PermitRootLogin without-password

I discovered this while setting up a Barracuda backup system for backing up a FreeBSD host. (On FreeBSD, its in /etc/ssh/sshd_config.)

Answer 2

Make sure there are no newlines in the key in your authorized_keys file - I had something like that bite me before. After hitting the backspace key all the way back to the last ascii character it suddenly started working.

Also, sshd is very particular about the permissions on the .ssh directory and its files.

here's one (of many) links with the permissions listed.

http://www.unixpeople.com/HOWTO/configuring.ssh.html

Answer 3

A copy of your sshd_config file would be interesting. In particular, the sshd requires the directive pubkeyauthentication to be set to yes:

PubkeyAuthentication yes

You might also want to specify the path for authorized_keys files

AuthorizedKeysFile     %h/.ssh/authorized_keys

Also, is the remote trying to connect to your local root ? in which case, you should also check permitrootlogin.

Hope it helps...

Answer 4

Can they login normally using a username and password? If not, it may be that their shell is set to nologin; check /etc/passwd to verify that their shell is setup correctly.

Answer 5

I had the same problem (CentOS 6.0). If SELinux is on, try doing the following:

restorecon -R -v /root/.ssh