SSH Key Authentication Not Working on RedHat 6/Oracle Linux 6: Why Does SSH Keep Asking for Password Despite Proper authorized_keys Setup?

Table of Contents#

1. Common Causes of SSH Key Authentication Failure
   • 1.1 Incorrect File/Directory Permissions
   • 1.2 SELinux Context Issues
   • 1.3 Misconfigured SSH Daemon (sshd_config)
   • 1.4 Unsupported Key Types or Formats
   • 1.5 Problematic User Home Directory Permissions
   • 1.6 Corrupted or Malformed authorized_keys Content
   • 1.7 SSH Service Misconfiguration or Restart Issues
2. Troubleshooting Steps: Diagnose and Fix
   • 2.1 Check Debug Output with ssh -v
   • 2.2 Inspect Server Logs (/var/log/secure)
   • 2.3 Verify Permissions and Ownership
   • 2.4 Fix SELinux Contexts
   • 2.5 Validate sshd_config Settings
   • 2.6 Ensure Compatibility with Key Types
3. Conclusion
4. References

Common Causes of SSH Key Authentication Failure#

1.1 Incorrect File/Directory Permissions#

OpenSSH on RHEL 6/OL 6 is notoriously strict about permissions for the .ssh directory and authorized_keys file. If these are too permissive (e.g., writable by other users), the SSH daemon (sshd) will ignore the authorized_keys file entirely, falling back to password authentication.

Why It Happens:#

sshd assumes that if ~/.ssh or ~/.ssh/authorized_keys is accessible to other users, it could be tampered with. To prevent this, it enforces strict ownership and permissions.

How to Check:#

Run these commands on the server (replace user with your target username):

# Check .ssh directory permissions
ls -ld /home/user/.ssh
 
# Check authorized_keys permissions
ls -l /home/user/.ssh/authorized_keys

Correct Permissions:#

1.2 SELinux Context Issues#

RedHat 6/OL 6 enable SELinux by default, which enforces file context labels. If the .ssh directory or authorized_keys file has an incorrect SELinux context (e.g., user_home_t instead of ssh_home_t), sshd will not recognize the keys, even if permissions are correct.

Why It Happens:#

SELinux labels files with contexts to restrict access. The ssh_home_t context is reserved for SSH-related files. If you copied authorized_keys from another system or modified the .ssh directory, its context may have been reset.

How to Check:#

Use ls -Z on the server to view SELinux contexts:

ls -Z /home/user/.ssh
ls -Z /home/user/.ssh/authorized_keys

Correct Context:#

The output should show ssh_home_t for both the directory and file:

drwx------. user user unconfined_u:object_r:ssh_home_t:s0 .ssh
-rw-------. user user unconfined_u:object_r:ssh_home_t:s0 authorized_keys

How to Fix:#

Restore the default SELinux context with restorecon:

restorecon -Rv /home/user/.ssh

1.3 Misconfigured SSH Daemon (sshd_config)#

The SSH daemon’s configuration file (/etc/ssh/sshd_config) controls key authentication behavior. If critical settings are missing or misconfigured, sshd will skip key authentication.

Key Settings to Verify:#

1. PubkeyAuthentication yes: Enables public key authentication (required).
2. AuthorizedKeysFile .ssh/authorized_keys: Specifies the path to authorized_keys (default, but confirm it’s not commented out).
3. PasswordAuthentication yes: While not directly causing the issue, if key auth fails, sshd falls back to password. However, this should not prevent key auth from working if configured correctly.
4. PermitRootLogin: If using root login, ensure this is set to yes or prohibit-password (though prohibit-password is preferred for key-only root access).
5. RSAAuthentication yes: For RSA keys (older RHEL 6 systems may require this, though deprecated in newer OpenSSH).

How to Check:#

Grep for these settings in sshd_config:

grep -E 'PubkeyAuthentication|AuthorizedKeysFile|PasswordAuthentication|PermitRootLogin|RSAAuthentication' /etc/ssh/sshd_config

How to Fix:#

Edit sshd_config with vi /etc/ssh/sshd_config, set the values above, then restart sshd:

service sshd restart

1.4 Unsupported Key Types or Formats#

RHEL 6/OL 6 ship with OpenSSH 5.3 (released in 2009), which does not support modern key types like Ed25519 or ECDSA (elliptic curve). If you generated an Ed25519 key (common in newer systems), sshd will ignore it and prompt for a password.

Supported Key Types for RHEL 6:#

• RSA: The most reliable (use 2048-bit or higher).
• DSA: Supported but insecure (avoid; DSA keys are limited to 1024 bits and vulnerable to attacks).

How to Check Key Type:#

On the client, check your private key type:

ssh-keygen -l -f ~/.ssh/id_rsa  # Replace with your key file

Output for RSA: 2048 SHA256:... user@client (RSA)
Output for Ed25519: 256 SHA256:... user@client (ED25519) (unsupported on RHEL 6).

How to Fix:#

Generate an RSA key instead:

ssh-keygen -t rsa -b 2048 -f ~/.ssh/id_rsa_rhel6

Then copy the new public key to the server’s authorized_keys.

1.5 Problematic User Home Directory Permissions#

If the user’s home directory (/home/user) is group- or world-writable, sshd may distrust the authorized_keys file, even if .ssh permissions are correct.

Why It Happens:#

A writable home directory could allow other users to modify .ssh or authorized_keys, so sshd treats it as unsafe.

How to Check:#

ls -ld /home/user

Correct Permission:#

The home directory should not be writable by others. Use chmod go-w to remove group/world write access:

chmod go-w /home/user

1.6 Corrupted or Malformed authorized_keys Content#

Even with correct permissions, authorized_keys may fail if its content is malformed. Common issues include:

• Extra whitespace or newlines between key entries.
• Incorrect key format (e.g., missing ssh-rsa prefix).
• Truncated or corrupted key strings.

How to Check:#

View authorized_keys on the server:

cat /home/user/.ssh/authorized_keys

Each line should be a single public key in the format:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ... user@client

How to Fix:#

• Ensure one key per line.
• Remove extra spaces/newlines.
• Re-append the public key from the client:

  # On client: copy public key to clipboard
  cat ~/.ssh/id_rsa.pub | xclip -sel clip  # Or manually copy
   
  # On server: append to authorized_keys (replace with your key)
  echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ..." >> /home/user/.ssh/authorized_keys

1.7 SSH Service Misconfiguration or Restart Issues#

If you modified sshd_config but forgot to restart sshd, changes won’t take effect. Similarly, a typo in sshd_config (e.g., PubkeyAuthentication ye instead of yes) can cause sshd to ignore key auth.

How to Check:#

• Verify sshd status:

  service sshd status

• Check for configuration errors:

  sshd -t  # Validates sshd_config syntax

How to Fix:#

• Restart sshd after config changes:

  service sshd restart

• Fix any syntax errors reported by sshd -t in sshd_config.

Troubleshooting Steps: Diagnose and Fix#

2.1 Check Debug Output with ssh -v#

The ssh client’s verbose mode (-v) reveals exactly what happens during authentication. Run this on the client:

ssh -v user@server_ip

What to Look For:#

• "Offering public key": The client is sending your key.
• "Server accepts key": The server recognizes the key (success!).
• "Authentications that can continue: publickey,password": Key auth failed; server falls back to password.
• "Permission denied (publickey,password)": Check server-side permissions/logs.

2.2 Inspect Server Logs (/var/log/secure)#

The server’s /var/log/secure log file contains detailed SSH authentication attempts. Look for errors here:

Common Log Entries:#

• Authentication refused: bad ownership or modes for directory /home/user → Fix home dir permissions.
• Could not open authorized keys '/home/user/.ssh/authorized_keys': Permission denied → Fix authorized_keys permissions.
• Invalid user key: /home/user/.ssh/authorized_keys → Malformed key in authorized_keys.

2.3 Verify Permissions and Ownership#

Walk through the permission checks again:

# Home dir: no group/world write
chmod go-w /home/user
 
# .ssh dir: 700, user:user
chmod 700 /home/user/.ssh
chown user:user /home/user/.ssh
 
# authorized_keys: 600, user:user
chmod 600 /home/user/.ssh/authorized_keys
chown user:user /home/user/.ssh/authorized_keys

2.4 Fix SELinux Contexts#

If SELinux is enabled (check with sestatus), restore contexts:

restorecon -Rv /home/user/.ssh  # Fixes ssh_home_t context

2.5 Validate sshd_config Settings#

Ensure these lines exist in /etc/ssh/sshd_config (uncommented):

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
RSAAuthentication yes  # For RSA keys (optional but safe)

Restart sshd afterward.

2.6 Ensure Compatibility with Key Types#

If using an Ed25519 or ECDSA key, generate an RSA key and re-upload it to authorized_keys.

Conclusion#

SSH key authentication failures on RHEL 6/OL 6 are almost always due to strict security policies, outdated software, or misconfigurations. By systematically checking permissions, SELinux contexts, key types, and sshd settings, you can resolve the "password prompt despite authorized_keys" issue.

Remember: RHEL 6 and Oracle Linux 6 are end-of-life (EOL), so consider upgrading to a supported distribution for better security. But for now, the steps above will get your key authentication working reliably.

References#

• Red Hat Enterprise Linux 6 Security Guide: SSH Keys
• OpenSSH sshd_config Man Page (RHEL 6)
• SELinux Context: ssh_home_t
• OpenSSH Legacy Key Support