When examining your verbose SSH output (ssh -v), we can see the authentication sequence fails at multiple stages:

debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/jsmith/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

On SELinux-enabled systems, we need to verify several context-related aspects:

# Check SELinux context of .ssh directory
ls -Z ~/.ssh/

# Expected output should include:
system_u:object_r:ssh_home_t:s0

If the context is incorrect, restore it with:

restorecon -R -v ~/.ssh

While you've set permissions correctly (700 for .ssh and 600 for files), let's verify recursively:

# Comprehensive permission check
namei -l ~/.ssh/authorized_keys

On the remote server, verify these settings in /etc/ssh/sshd_config:

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no  # For key-only access
ChallengeResponseAuthentication no
UsePAM no

After changes, reload SSH:

systemctl reload sshd

Enable deeper logging on the server side:

# Add to /etc/ssh/sshd_config
LogLevel DEBUG3

# Then monitor logs in real-time:
journalctl -fu sshd

Manually test key authentication with:

ssh -v -i ~/.ssh/id_rsa user@host

For thorough testing, create a new key pair:

ssh-keygen -t ed25519 -f ~/.ssh/new_key
ssh-copy-id -i ~/.ssh/new_key user@host

---

From your verbose output, we can see the authentication flow clearly fails at the publickey method before falling back to password:

debug1: Next authentication method: publickey
debug1: Offering public key: /home/jsmith/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

The most probable culprit on SELinux systems is incorrect security context. Run these checks:

ls -Z ~/.ssh/authorized_keys
# Should show: unconfined_u:object_r:ssh_home_t:s0

restorecon -Rv ~/.ssh
chcon -R -t ssh_home_t ~/.ssh

Verify these critical settings in /etc/ssh/sshd_config:

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no # For testing only
UsePAM no # Temporary test

Beyond standard 600/700 permissions, SELinux requires:

chmod 711 ~/
chmod 755 ~/.ssh
chmod 644 ~/.ssh/authorized_keys

Check detailed audit logs with:

ausearch -m avc -ts recent
grep sshd /var/log/audit/audit.log | grep denied

Sometimes required for home directory access:

setsebool -P ssh_home_dir 1
getsebool -a | grep ssh

For quick verification, try running SELinux in permissive mode temporarily:

setenforce 0
# Attempt SSH connection
setenforce 1 # Remember to re-enable

If this works, you've confirmed an SELinux policy issue rather than a basic SSH configuration problem.

• Verify sshd actually reloaded config (systemctl status sshd)
• Check for multiple authorized_keys files (some systems use /etc/ssh/authorized_keys)
• Test with stripped-down key file (single key, no comments)
• Confirm client isn't overriding identity with -i or config directives