When SELinux prevents passwordless SSH authentication despite correct file permissions and SSH key setup, we're typically dealing with either security context mismatches or missing boolean flags. The audit log entry you provided shows a failed login attempt with no specific file violation - which means we need to investigate deeper.

First, verify the complete context chain with:

# Check SSH daemon context
ps -eZ | grep sshd

# Verify complete directory context
ls -laZ /root/ | grep .ssh
ls -laZ /root/.ssh/

The presence of system_u:system_r:sshd_t in logs refers to the SELinux context of the SSH daemon process itself, not files. This is normal and indicates the process is running under expected confinement.

For passwordless SSH to work, these contexts must be correct:

/root/ - should have: system_u:object_r:admin_home_t:s0
/root/.ssh/ - should have: system_u:object_r:ssh_home_t:s0
/root/.ssh/authorized_keys - must have: system_u:object_r:ssh_home_t:s0

If contexts appear correct but it's still failing, try these in order:

# 1. Restore contexts recursively
restorecon -R -v /root/.ssh

# 2. Check boolean settings
getsebool -a | grep ssh

# 3. Temporarily set permissive mode for testing
setenforce 0
# Attempt SSH login
# If it works, check audit logs for denials:
ausearch -m AVC -ts recent
setenforce 1

On CentOS 7/RHEL systems, this boolean is critical:

setsebool -P ssh_home_dir 1

This allows sshd to access home directory SSH files even when they're in non-standard locations or under /root.

For persistent context issues, create a custom policy module:

# Generate .te file from audit logs
ausearch -m avc -ts recent | audit2allow -m mypolicy > mypolicy.te

# Check the generated file
cat mypolicy.te

# Compile and install
checkmodule -M -m -o mypolicy.mod mypolicy.te
semodule_package -o mypolicy.pp -m mypolicy.mod
semodule -i mypolicy.pp

Combine SELinux debugging with SSH client verbosity:

ssh -vvv root@yourserver

This often reveals whether the failure occurs before or after key authentication attempts, helping pinpoint the security layer causing the block.

When SELinux interferes with SSH key-based authentication, it typically manifests as silent failures with minimal logging. The key indicators in your case are:

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'

Your file contexts appear correct at first glance:

# 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

Several often-overlooked SELinux factors can affect SSH authentication:

# Verify SELinux boolean for SSH key auth
getsebool -a | grep ssh

Expected output should include:

ssh_keysign --> off
allow_ssh_keysign --> off
ssh_sysadm_login --> on

For deeper investigation, use these tools:

# Check for SELinux denials
sealert -a /var/log/audit/audit.log

# Alternative using audit2why
ausearch -m avc -ts recent | audit2why

# Check process context during connection attempt
ps -eZ | grep sshd

Here's the complete remediation process:

# 1. Reset contexts properly
restorecon -R -v /root/.ssh

# 2. Set correct boolean values
setsebool -P ssh_sysadm_login on
setsebool -P allow_ssh_keysign on

# 3. Rebuild policy module if needed
grep sshd /var/log/audit/audit.log | audit2allow -M mypol
semodule -i mypol.pp

# 4. Verify with test connection
ssh -v root@localhost

To ensure contexts survive reboots and relabeling:

# Add custom file context definition
echo "/root/.ssh(/.*)? system_u:object_r:ssh_home_t:s0" >> /etc/selinux/targeted/contexts/files/file_contexts.local

# Apply the new definitions
restorecon -R -v /root/.ssh
semanage fcontext -l | grep ssh_home_t