On fedora 16
I copied my public key to /home/user/.ssh/authorized_keys file
user comes from ldap.
But could not authenticate over ssh without password for this user.
It works for root.
strace on sshd
[pid 24834] setgroups(1, [1100]) = 0
[pid 24834] getgroups(0, NULL) = 1
[pid 24834] getgroups(1, [1100]) = 1
[pid 24834] setgroups(1, [1100]) = 0
[pid 24834] setresgid(-1, 1100, -1) = 0
[pid 24834] setresuid(-1, 1040, -1) = 0
[pid 24834] open("/home/user/.ssh/authorized_keys", O_RDONLY|O_NONBLOCK) = -1 EACCES (Permission denied)- I tried to access to the file with user account: no problem.
- I tried with a tiny C program with same options above: no problem.
- I tried with 777 right: no problem.
ls -l on authorized_keys file:
-rw-r--r--. 1 user user 784 19 nov. 16:24 authorized_keys- I tried to disable StrictMode (and restarting sshd)
I compared with an other fedora 16:
- same OS
- same sshd_config file
- same permissions on
~/,~/.ssh/and~/.ssh/authorized_keys
And now, I don't know what to try to troubleshoot it.
14 Answers
It might be SE Linux. If the context of the file isn't correct, running this as root should fix.
restorecon -Rv /home/user/.sshAlso check the permissions on /home/user/.ssh aren't wide open. SSHD is quite particular about this.
chmod 0700 /home/user/.sshI had a similar issue, and in my case the cause was wrong ownership of both the .ssh directory and .ssh/authorized_keys file. To fix that, in /home/user as root:
chown user:user .ssh
chown user:user .ssh/authorized_keysYour authorized_keys file should have permissions rw-------. Run:
chmod 600 ~/.ssh/authorized_keysAnd just as a note your private key (typically id_rsa) on the client should have the same permissions.
Further to fredden's answer (I don't have enough reputation to comment), I had a similar problem on RHEL 7, after setting LogLevel DEBUG3 in sshd_config (and restarting sshd service) I got the following in /var/log/secure:
datetime servername sshd[11180]: debug1: Could not open authorized keys '/authorized_keys/authorized_keys': Permission denied
Despite the folder and file having correct permissions (700 and 600 respectively).
If you suspect it might be SElinux (which mine turned out to be), you can check it by looking in /var/log/audit/audit.log and searching for the filename (in this case authorized_keys ). If this is the culprit you'll find a deny entry with type=AVC.
I just put SELinux in permissive mode which probably isn't the best approach but short on time and it fixed it. I didn't try the restorecon -Rv /home/user/.ssh because I didn't realise this was the relevant (didn't realise it was SELinux causing the problem at first) until afterwards.
