Why is selinux blocking remote ssh access without a password?

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.

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.

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