Why is selinux blocking remote ssh access without a password?

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

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.

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.