You've done everything by the book: generated keys, copied the public key to ~/.ssh/authorized_keys, but still get prompted for a password. The server seems to completely ignore your SSH key authentication attempt. Let's systematically diagnose this.

SSH is notoriously strict about permissions. Run these checks on your server:

# Check directory permissions
ls -ld ~/ ~/.ssh ~/.ssh/authorized_keys

# Correct permissions (server-side)
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 755 ~/

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

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no  # For testing purposes

After editing, restart SSH: sudo systemctl restart sshd

Instead of DSA (now considered weak), generate ED25519 or RSA keys:

ssh-keygen -t ed25519 -f ~/.ssh/mykey -C "workstation-key"
ssh-keygen -t rsa -b 4096 -f ~/.ssh/myrsakey -C "backup-key"

Run SSH in verbose mode to see exactly what's happening:

ssh -vvv user@server

Look for these critical lines in the output:

debug1: Offering public key: ...
debug1: Server accepts key: ...
debug1: Authentication succeeded (publickey).

On RHEL/CentOS systems, check and restore context:

ls -Z ~/.ssh/authorized_keys
restorecon -Rv ~/.ssh

If home directories are mounted with noexec or special options, it can break SSH key auth. Check /etc/fstab and mount output.

Ensure your authorized_keys has exactly one key per line, with no extra whitespace:

ssh-ed25519 AAAAC3Nz... comment
ssh-rsa AAAAB3Nz... comment
# No empty lines or spaces before keys

• Client key exists in ~/.ssh/id_*
• Public key copied to server's authorized_keys
• Correct permissions on all files/directories
• SSH daemon properly configured
• No firewall blocking SSH
• Key type supported by server (check ssh -Q key)

---

When SSH key authentication fails silently, you might observe these behaviors:

# Typical symptoms:
$ ssh user@server
user@server's password: # Still prompts for password
# No error messages in client output
# No relevant entries in server auth logs

First verify these critical server settings:

# /etc/ssh/sshd_config must contain:
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no # Optional but recommended

# Permission requirements:
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys

Broken key formats are a common culprit. Validate with:

# Check key format integrity:
$ ssh-keygen -l -f ~/.ssh/authorized_keys
# Proper output shows key fingerprint:
# 2048 SHA256:AbCdE... user@host (RSA)

Enable client-side debugging:

$ ssh -vvv user@server
# Look for these critical lines:
debug1: Offering public key: /home/user/.ssh/id_dsa
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51

On SELinux-enabled systems:

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

For non-standard key locations:

$ ssh -i /path/to/private_key user@server
# Corresponding server config:
AuthorizedKeysFile .ssh/authorized_keys /etc/ssh/keys/%u

Check for forced commands in authorized_keys:

# Example of problematic entry:
command="/bin/false" ssh-dss AAAAB3...== user@host
# Remove any command= prefixes during testing

Server-side log examination (as root):

# Tail auth logs in real-time:
$ tail -f /var/log/auth.log | grep sshd
# Common rejection messages:
# Authentication refused: bad ownership or modes

Modern systems may reject DSA keys. Generate RSA instead:

$ ssh-keygen -t rsa -b 4096
# Update sshd_config:
HostKeyAlgorithms ssh-rsa,rsa-sha2-256,rsa-sha2-512