You're trying to connect to a server using SSH key authentication, but you keep getting rejected:
$ ssh user@server.example.com
user@server.example.com: Permission denied (publickey).This error means the server rejected your public key authentication attempt. The cause could be on your local machine, the server, or somewhere in between. Let's diagnose and fix this systematically.
Diagnose the Problem
Start by running SSH with verbose output to see exactly where authentication fails:
ssh -v user@server.example.comFor more detail, use up to three -v flags:
ssh -vvv user@server.example.comLook for lines like these in the output:
debug1: Offering public key: /home/you/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/you/.ssh/id_rsa
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickeyThis tells us SSH offered your key but the server rejected it. The problem is likely on the server side.
Check Local Key Permissions
SSH is strict about file permissions. Wrong permissions on your private key will cause rejection:
ls -la ~/.ssh/id_rsaCorrect permissions should show:
-rw------- 1 you you 1679 Apr 3 10:00 /home/you/.ssh/id_rsaIf permissions are too open, fix them:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pubFor the directory containing your SSH files:
chmod 700 ~/.sshVerify the Public Key on the Server
The most common cause is that your public key isn't in the server's authorized_keys file. SSH into the server using password authentication:
ssh -o PreferredAuthentications=password user@server.example.comCheck if your public key exists:
cat ~/.ssh/authorized_keysIf the file doesn't exist or your key is missing, add it. First, copy your public key from your local machine:
cat ~/.ssh/id_rsa.pubOn the server, add it to authorized_keys:
mkdir -p ~/.ssh
echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ..." >> ~/.ssh/authorized_keysOr use ssh-copy-id from your local machine:
ssh-copy-id user@server.example.comCheck Server-Side Permissions
On the server, verify permissions for the SSH directory and files:
ls -la ~/.ssh/Correct output:
total 8
drwx------ 2 user user 4096 Apr 3 10:00 .
drwxr-xr-x 6 user user 4096 Apr 3 09:00 ..
-rw------- 1 user user 400 Apr 3 10:00 authorized_keysFix permissions if needed:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keysAlso check your home directory permissions:
ls -ld ~Your home directory should not be writable by group or others:
chmod go-w ~Check SSHD Configuration
On the server, verify the SSH daemon allows public key authentication:
sudo grep -E "^(PubkeyAuthentication|AuthorizedKeysFile|PasswordAuthentication)" /etc/ssh/sshd_configExpected output:
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication noIf PubkeyAuthentication is set to no, change it:
sudo sed -i 's/^PubkeyAuthentication no/PubkeyAuthentication yes/' /etc/ssh/sshd_configIf the line doesn't exist, add it:
echo "PubkeyAuthentication yes" | sudo tee -a /etc/ssh/sshd_configThen restart SSH:
sudo systemctl restart sshdCheck SELinux or AppArmor
On systems with SELinux (RHEL, CentOS, Fedora), incorrect context can block access:
restorecon -R -v ~/.sshCheck SELinux status:
getenforceIf enforcing, you can temporarily set to permissive to test:
sudo setenforce 0If this fixes the issue, the problem was SELinux context.
Verify the Key Type
Newer SSH versions might reject older or less secure key types. Check your key:
ssh-keygen -l -f ~/.ssh/id_rsa.pubIf you're using DSA or RSA keys smaller than 2048 bits, generate a new ED25519 key:
ssh-keygen -t ed25519 -C "your_email@example.com"
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server.example.comTest the Connection
After making changes, test the connection:
ssh -v user@server.example.comLook for:
debug1: Authentication succeeded (publickey).Quick Checklist
- 1.Private key permissions:
600(owner read/write only) - 2.
.sshdirectory permissions:700(owner only) - 3.
authorized_keyspermissions:600(owner read/write only) - 4.Home directory not writable by group/others
- 5.Public key present in
authorized_keys - 6.
PubkeyAuthentication yesinsshd_config - 7.Correct SELinux/AppArmor context
The most common fix is adding your public key to ~/.ssh/authorized_keys on the server with correct permissions. Run through this checklist methodically and you'll resolve the permission denied error.