Permission denied (publickey)

The server rejected your SSH key authentication.

Frequently documented in developer and vendor support forums.

• Wrong key file
• Key not in authorized_keys
• Incorrect file permissions

1. Add key to ~/.ssh/authorized_keys
2. Set correct permissions (chmod 600)
3. Specify correct key with -i flag

Last reviewed: March 2026 How we review solutions

SSH "Permission denied (publickey)" means the SSH server rejected all authentication methods your client offered, and only public key authentication was available. The SSH handshake involves the client presenting a public key, the server checking if that key appears in the target user's ~/.ssh/authorized_keys file, and then the client proving it holds the matching private key. A failure at any of these steps produces this error. The most common cause is incorrect file permissions: OpenSSH is deliberately strict—if the ~/.ssh directory is world-readable (permissions above 700) or the private key file is readable by others (permissions above 600), the SSH client refuses to use the key as a security precaution. The second most common cause is the public key not being present in authorized_keys on the server. This happens after server reinstalls, user account recreation, or when you generated a new key pair locally without copying the public half to the server. SSH agent issues are another frequent source: if the agent is not running or the key is not loaded into it, the client has no key to offer. GitHub and GitLab SSH access adds another dimension—these services match your key against your account, and if the key is associated with a different account or was removed from your settings, authentication fails even though the key pair is technically valid.

1. Check private key permissions: ls -la ~/.ssh/id_* (should be 600 or 400)
2. Verify .ssh directory permissions: ls -la ~ | grep .ssh (should be 700)
3. Test with verbose output: ssh -vvv user@host to see which keys are tried
4. Confirm your public key is in ~/.ssh/authorized_keys on the server
5. Check if ssh-agent is running and the key is loaded: ssh-add -l
6. For GitHub: run ssh -T git@github.com to test your key

SELinux blocking SSH key access

On RHEL/CentOS with SELinux enabled, even correct file permissions can be blocked if the SELinux context is wrong. Run restorecon -R ~/.ssh on the server to reset the security context to the expected labels.

SSH config specifying wrong key file

If ~/.ssh/config has an IdentityFile directive pointing to a non-existent or wrong key for a specific host, SSH uses that key instead of the default. Check the Host block in your SSH config for the target server.

Ed25519 key on old SSH server

Ed25519 keys are not supported by OpenSSH versions before 6.5. If the server runs an older version, your ed25519 key will be silently ignored and authentication fails. Generate an RSA key as a fallback.

What permissions for .ssh?

.ssh should be 700, keys 600, authorized_keys 644.

How do I add my key?

Use ssh-copy-id user@host or manually append to authorized_keys.

Why does SSH care about file permissions?

If your private key is readable by other users on the system, anyone with access to the machine could impersonate you. SSH refuses to use keys with overly permissive access as a security measure to prevent this.

How do I use different SSH keys for different servers?

Create a ~/.ssh/config file with Host blocks. For each host, set IdentityFile to the specific key: Host github.com → IdentityFile ~/.ssh/github_key. SSH will automatically use the right key for each connection.

What if I lost my private key but still have server access?

Generate a new key pair with ssh-keygen, then add the new public key to ~/.ssh/authorized_keys on the server using your existing access method (console, another key, password if enabled). Remove the old public key from authorized_keys.

• Linux Man Pages – man7.org
• Linux Kernel Documentation