Why is selinux blocking remote ssh access without a password?

Question

I've got a CentOS 7 server. I've set up /root/.ssh/authorized_keys on the host I'm trying to login to without a password. (Yes, allowing remote root access is a bad idea but this is an internal server.) ssh fails and there's this in the selinux audit log.

type=USER_LOGIN msg=audit(1494544798.597:481313): pid=18660 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="root" exe="/usr/sbin/sshd" hostname=? addr=xx.xx.xx.xx terminal=ssh res=failed'

Here are the permissions and context of the .ssh stuff:

# ls -aZ /root/.ssh
drwx------. root root system_u:object_r:ssh_home_t:s0  .
dr-xr-x---. root root system_u:object_r:admin_home_t:s0 ..
-rw-------. root root system_u:object_r:ssh_home_t:s0  authorized_keys
-rw-r--r--. root root unconfined_u:object_r:ssh_home_t:s0 known_hosts

I've compared the permissions and contexts to those of another system that allows ssh login without a password and they're the same.

In the audit message there's no indication of what file selinux is concerned about, just "res=fail".

In the system that works the log entry has this in it:

subj=system_u:system_r:sshd_t:s0-s0:c0.c1023

So, I'm confused. There is no file in /root/.ssh that has context system_u:system_r:sshd_t. So, I don't understand why that context is logged.

Is there a way to know what the context of all .ssh-related files should be? Yes, I've played with restorecon with no luck.

Answer 1

You are quick to jump on SELinux....are you sure you have /etc/ssh/sshd_config properly set to allow root access via ssh? Have you restarted the sshd service if you have made any changes to the configuration files.

Have you tried setting SELinux to permissive and testing this.

You know, if SELinux was denying access I'd expect to see some type of AVC (Access Vector Cache) error in the /var/log/audit/audit.log. Remember that the audit.log is used for more than just SELinux issues. Thus all you are getting is simply a failed login report NOT an SELinux error.

Are you absolutely sure that the public/private openssh key pair you have actually works in an ssh context. You can try logging using the ssh command with -v option(s) to debug this and see.

I'd also be checking the /var/log/messages and /var/log/secure files for more information.

Answer 2

There is a short article on this issue. It says that

may be because the SELinux contexts have not been correctly set on the .ssh folder and authorized keys file [...] The way to fix this is to run

# restorecon -R -v /root/.ssh

The article also shows how to set permissions correctly from the beginning:

# chmod 755 /root/.ssh/
# chmod 600 /root/.ssh/authorized_keys
# restorecon -R -v /root/.ssh

Though I disagree with the article on the first command since on my VPS I have

# chmod 700 /root/.ssh/

From my personal experience, I have learned several important things about ssh-key authentification.

1. If you have new versions of OpenSSH (my problems started with OpenSSH 7.0) then DSA keys will not work, because "Support for ssh-dss host and user keys is disabled by default at run-time". The solution is either to use RSA keys or add PubkeyAcceptedKeyTypes=+ssh-dss to /etc/ssh/sshd_config on the remote machine and to ~/.ssh/config on the client machine.
2. Debugging the problems on the client side can be done by adding option -vvvvv to ssh call ssh -vvvvvv [email protected]
3. Debugging the problems on the server side can be done by editing /etc/ssh/sshd_config

SyslogFacility AUTH

LogLevel DEBUG

(help on options can be obtained by # man sshd_config)

Then during ssh connection look at /var/log/debug. If you cannot find debug log, look at /var/log/messages and /var/log/secure (as the last resort see what settings you have in /etc/syslog.conf).

Answer 3

In cases where restorecon -R -v ~/.ssh does not work, and SELinux is to blame per sealert or audit2allow reports, and when the SELinux contexts for the .ssh folder are altered, the following can fix logon issues with key-based authentication:

$ sudo semanage fcontext --add -t ssh_home_t "/path/to/my/.ssh(/.*)?"; \
$ sudo restorecon -FRv /path/to/my/.ssh

This fix was effective when AVCs of the sort shown below were observed:

$ sudo audit2allow -w -a
type=AVC msg=audit(1548909218.552:1037): avc:  denied  { read } for  pid=13996 comm="sshd" name="authorized_keys" dev="dm-0" ino=4663556 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=file
        Was caused by:
                Missing type enforcement (TE) allow rule.

                You can use audit2allow to generate a loadable module to allow this access.

Answer 4

I had this problem on CentOS 7. I am a regular Debian-based Linux user so I was a fish out of the water. I noticed that in some of the servers it worked and in just one it didn't. The audit.log said nothing useful and the secure.log did not give anything either. I found that the only real difference was some security context differences on files and directories between those that worked and those that didn't. Get the security with

sudo ls -laZ <user-home>/.ssh

of the directory (I'm assuming a lot of defaults on sshd_config).

You should see some ssh_home_t and user_home_t attributes. If you don't, use the chcon command to add the missing attributes.

For example:

home="$(getent passwd <user> | cut -d: -f6)"
sudo chcon -R unconfined_u:object_r:ssh_home_t:s0 "$home/.ssh"
sudo chcon unconfined_u:object_r:user_home_t:s0 "$home"

In my case, my suspicion is that the user was created in a non standard way. His home was a directory in /var/lib.

More info in: https://www.linuxquestions.org/questions/linux-security-4/selinux-preventing-ssh-login-with-~-ssh-authorized_keys-4175469538/

Answer 5

In my case was looking into

root#> journalctl -f

then tell SELinux that use to nfs home dirs is allowed:

root#> setsebool -P use_nfs_home_dirs 1

This solve my problem.