16

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.

2
  • Is there nothing else different with the machine? Apparmor? Networked home directory? Etc? Commented Nov 19, 2013 at 17:34
  • still relevant 10 years later on fc39
    – Phil
    Commented Jan 28 at 20:57

4 Answers 4

19

It might be SE Linux. If the context of the file isn't correct, running this as root should fix.

restorecon -Rv /home/user/.ssh

Also check the permissions on /home/user/.ssh aren't wide open. SSHD is quite particular about this.

chmod 0700 /home/user/.ssh
1
  • Doesn't need to be "wide open", 0600 for example will lead to the same problem (for different reasons though).
    – kraxor
    Commented Mar 23, 2021 at 23:29
8

I 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_keys
2
  • same but I fixed by recreating the folder/file
    – CervEd
    Commented Apr 7, 2021 at 19:18
  • Just to Clarify, all these commands need to be run on the SERVER, not on the local machine because authorized_keys is being created on the machine you are trying to connect to!
    – gavin
    Commented May 17, 2023 at 3:19
2

Your authorized_keys file should have permissions rw-------. Run:

chmod 600 ~/.ssh/authorized_keys

And just as a note your private key (typically id_rsa) on the client should have the same permissions.

2
  • nop, does not work better :(
    – trax
    Commented Nov 19, 2013 at 17:37
  • 2
    @trax does it still give you the same error? Either in strace or in ssh -vvv or so?
    – terdon
    Commented Nov 19, 2013 at 17:54
1

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.

1
  • Just to add to this, if you're connecting remotely and don't want to restart sshd because of potential inability to reconnect on failure, and you have access to the firewall config, you can run a second sshd in debug mode on a different listen port to get similar output. e.g. open port 1234 over the firewall, then run: sshd -d -p 1234 and when connecting from the client: ssh -p 1234 user@hostname .. the sshd will output debug messages to the console without interrupting the normal sshd on port 22.
    – Neek
    Commented Jun 9, 2022 at 4:17

You must log in to answer this question.

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