RedHat 6/Oracle Linux 6 is not allowing key authentication via ssh

Question

Keys are properly deployed in ~/.ssh/authorized_keys

Yet ssh keeps on prompting for a password.

Velasco

Check /var/log/secure it will have information if the public key failed for auth. Most likely file(s) have the wrong read/write permission in ~/.ssh. – Ianiana

In my case perms were fine. it was SELinux related, see below – Velasco

Answer 1

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

Velasco

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 – Xerophilous

Yes, it should be owner access only. In my rhel6 box still works with 600 – Xerophilous

You mean my suggestion was bad? because I see that you edited your response with 600 for the files. – Xerophilous

forgot to update my comment, I had the file ownership wrong (note the chown addition). so your suggestion was fine. – Velasco

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(/.*)?" – Huss

Answer 2

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.

Doubledecker

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! – Huss

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.) – Huss

Corrected command: semanage fcontext -a -t ssh_home_t "/path/to/service/home/\.ssh(/.*)?" – Huss

Answer 3

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

Flywheel

Did this instruction solve the case for you? Or is it just a compilation? – Yarmouth

Answer 4

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.

Calvinism

You probably mean o-rwx, not u-rwx :) – Panorama

Good catch! I have a recurring mnemonic issue with 'u' and 'o' in the chmod/chown commands. 'o' is 'other', not 'owner'! – Calvinism