12

Keys are properly deployed in ~/.ssh/authorized_keys

Yet ssh keeps on prompting for a password.

Olivier Refalo
  • 50,287
  • 22
  • 91
  • 122

4 Answers4

29

Several issues, mostly privileges - but also related to SELinux on RedHat 6

The following script should fix them all, please replace <user>:<group> with your matching userid and group

chown -R <user>:<group> ~/.ssh
chmod 700 ~/.ssh
chmod 600 ~/.ssh/*
restorecon -R -v ~/.ssh
Sergiu Dumitriu
  • 11,455
  • 3
  • 39
  • 62
Olivier Refalo
  • 50,287
  • 22
  • 91
  • 122
  • 3
    you should not change the file permissions to be world readable even if they are inside a protected directory `restorecon -R -v $HOME/.ssh` is what did the trick for me – feniix Apr 01 '13 at 22:47
  • Yes, it should be owner access only. In my rhel6 box still works with 600 – feniix Apr 02 '13 at 17:23
  • You mean my suggestion was bad? because I see that you edited your response with 600 for the files. – feniix Apr 11 '13 at 16:05
  • 1
    forgot to update my comment, I had the file ownership wrong (note the chown addition). so your suggestion was fine. – Olivier Refalo Apr 12 '13 at 13:54
  • Note that this only works for standard home directories. If you are applying this change to a service account, or some other user whose home directory is not in /home, then you need to add the following command before restorecon (or rerun restorecon after running this command, replace path/to/service/home with the FULL home path): semanage fcontext -a -t ssh_home_t "/path/to/service/home/\.ssh(/.*)?" – BamaPookie Jul 07 '15 at 16:16
6

I'd agree with the changes above working on most linux variants in the root account. I have had a problem with RedHat 6.3 with trying to get a postgres user account to use DSA auth. (6.3 running in VirtualBox)

The issue can be that the basic selinux permissions are wrong. Restorecon wont help in this case. 

(After restorecon)
drwx------. postgres postgres unconfined_u:object_r:var_lib_t:s0 .ssh

I have fixed this with :

chcon -R -t ssh_home_t .ssh

This resolved this instance of the problem.

Greg Hardy
  • 61
  • 1
  • 1
  • I have been searching for three days for this answer! It wasn't until I ran stat on the authorized keys file that I noticed an SELinux context on the file. I compared it to an authorized keys file for a different user and noticed the difference! Thank you, Greg! – BamaPookie Jul 07 '15 at 15:02
  • One additional point I discovered: If you subsequently run restorecon on this .ssh directory, you will lose the changes you made with the chcon command. You need to also add a policy that will reapply the context properly upon a filesystem relabel. I did this with the following command: semanage fcontext -a -t ssh_home_t "/path/to/service/home/.ssh(/.*)?". (Be sure to use the full path.) – BamaPookie Jul 07 '15 at 15:43
  • 2
    Corrected command: semanage fcontext -a -t ssh_home_t "/path/to/service/home/\.ssh(/.*)?" – BamaPookie Jul 07 '15 at 16:13
1

I had also this same issue, the proposed solution above did not solve the case for me. To summarise instructions abowe together:

  1. Check following logfile on target system for possible details of errors: /var/log/secure
  2. Permission of files in users ~/.ssh directory should be 600 and files should be owned By "user:group"
  3. Permission of ~/.ssh directory should be 700 and owned By "user:group"
  4. Permission of home directory of user ie. "~" (="~/.ssh/..") should be 755. If permissions are f.ex 775, ssh key autenthication failed in my system.

br bruno

aa2_bruno
  • 11
  • 1
0

The above answer is quite good, I have an addition & a suggestion. The addition is in line 2 below, as home directory permissions not be more permissive than rwxr-x--- for ssh key authentication.

cd ~
chmod g-w,o-rwx .
chmod 700 .ssh
cd .ssh
chmod 600 *
chmod 644 authorized_keys
chmod 644 known_hosts
chmod 644 config
restorecon -R -v ../.ssh

The suggestion is to make use of the -vv option when testing.

nortally
  • 347
  • 2
  • 9