You maybe have run into this scenario if you use dedicated servers from many providers or function as a consultant on varying implementations of SELinux enabled systems. The issue is simple but confusing if one is not versed in SELinux operations. This applies to any Linux variant running SELinux extensions (RHEL, CentOS, Fedora, etc).
Issue: I have the root password but I don’t want to use my password and would prefer to SSH using a RSA/DSA key exchange. So I SSH to the server as root and put in my password, then I add my public key to the /root/.ssh/authorized_keys file and ensure that the file is chmod 644. I logout and login hoping to not be prompted for a password; but alas! It does not work and the /var/log/secure file tells me nothing useful.
Error: you’ll see log entries similar to this in the /var/log/audit/audit.log file:
type=USER_LOGIN msg=audit(1351870457.015:7444): user pid=11918 uid=0 auid=0 ses=43 subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 msg=’op=login acct=”root” exe=”/usr/sbin/sshd” hostname=? addr=
Solution: A lot of users get frustrated by SELinux and do not want to take the time to learn how to use it, so you can foolishly turn off SELinux although I’m not posting that here to enable lazy users, or you can set the security context for the /root/.ssh directory and files via this command: restorecon -R -v /root/.ssh
End result: Once the context has been restored you will see successful logins in the audit.log file as such: type=CRYPTO_KEY_USER msg=audit(1351870483.100:7492): user pid=11928 uid=0 auid=0 ses=49 subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 msg=’op=destroy kind=server fp=33:cf:25:a6:f4:4b:02:9e:26:a4:8c:10:76:3a:90:57 direction=? spid=11928 suid=0 exe=”/usr/sbin/sshd” hostname=? addr=
