Fix: SSH Permission denied (publickey,password)

The Error

You try to SSH into a server and get:

Permission denied (publickey,password).

Or variations:

Permission denied (publickey).

Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

user@server: Permission denied (publickey,password).

The SSH server rejected your authentication. None of the authentication methods you offered (public key, password, or others) were accepted.

Why This Happens

SSH authentication works in stages. The client offers credentials (key or password), and the server checks them. When all methods fail, the server returns “Permission denied” with the list of methods it supports.

Common causes:

• Wrong SSH key. The key you are offering does not match any authorized key on the server.
• Wrong username. You are connecting as the wrong user.
• SSH key not added to the agent. Your key exists but the SSH agent is not using it.
• Incorrect file permissions. The ~/.ssh directory or key files have wrong permissions.
• Password authentication disabled. The server only accepts key-based authentication.
• Key not authorized on the server. Your public key is not in ~/.ssh/authorized_keys.
• Server configuration issue. sshd_config restricts which users or keys can connect.

Fix 1: Check the Username

The most overlooked fix. Make sure you are connecting as the correct user:

ssh ubuntu@server.example.com     # Ubuntu EC2
ssh ec2-user@server.example.com   # Amazon Linux
ssh root@server.example.com       # Root (if allowed)
ssh admin@server.example.com      # Debian
ssh myuser@server.example.com     # Custom user

Common default users by platform:

If you SSH without specifying a user (ssh server.example.com), SSH uses your local username, which might not exist on the server.

Fix 2: Specify the Correct SSH Key

If you have multiple SSH keys, specify which one to use:

ssh -i ~/.ssh/my-key.pem user@server.example.com

Check which keys are available:

ls -la ~/.ssh/

Common key files:

• id_rsa / id_rsa.pub — RSA key pair
• id_ed25519 / id_ed25519.pub — Ed25519 key pair (recommended)
• *.pem — AWS EC2 key pairs

Check which key SSH is trying to use:

ssh -v user@server.example.com

Look for lines like:

debug1: Offering public key: /home/user/.ssh/id_ed25519
debug1: Server accepts key: /home/user/.ssh/id_ed25519

Or:

debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: No more authentication methods to try.

If none of your keys are accepted, the correct key is not being offered.

Pro Tip: Use ~/.ssh/config to map hostnames to keys:

Host myserver
    HostName server.example.com
    User ubuntu
    IdentityFile ~/.ssh/my-key.pem

Then simply: ssh myserver

Fix 3: Add Your Key to the SSH Agent

The SSH agent manages your keys. If your key is not loaded, SSH does not offer it:

# Start the agent (if not running)
eval "$(ssh-agent -s)"

# Add your key
ssh-add ~/.ssh/id_ed25519

# List loaded keys
ssh-add -l

For AWS .pem keys:

chmod 400 ~/.ssh/my-key.pem
ssh-add ~/.ssh/my-key.pem

macOS Keychain:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

Add to ~/.ssh/config to persist across reboots:

Host *
    AddKeysToAgent yes
    UseKeychain yes
    IdentityFile ~/.ssh/id_ed25519

Fix 4: Fix File Permissions

SSH is strict about permissions. Wrong permissions cause silent authentication failure:

# Fix directory permissions
chmod 700 ~/.ssh

# Fix private key permissions
chmod 600 ~/.ssh/id_ed25519
chmod 600 ~/.ssh/id_rsa
chmod 400 ~/.ssh/*.pem

# Fix public key permissions
chmod 644 ~/.ssh/id_ed25519.pub

# Fix authorized_keys permissions
chmod 600 ~/.ssh/authorized_keys

# Fix ownership
chown -R $(whoami):$(whoami) ~/.ssh

On the server side too:

chmod 700 /home/user/.ssh
chmod 600 /home/user/.ssh/authorized_keys
chown -R user:user /home/user/.ssh

If the .ssh directory or key files are world-readable, SSH refuses to use them. This is a security feature.

Common Mistake: Setting permissions to 777 or 666 on SSH files. SSH intentionally rejects keys with overly permissive permissions. Private keys must be 600 (owner read/write only) and the .ssh directory must be 700.

Fix 5: Add Your Public Key to the Server

Your public key must be in ~/.ssh/authorized_keys on the server:

Copy your public key to the server:

ssh-copy-id user@server.example.com

If ssh-copy-id is not available or password auth is disabled, copy manually:

# On your local machine
cat ~/.ssh/id_ed25519.pub
# Copy the output

# On the server (via console access)
mkdir -p ~/.ssh
echo "ssh-ed25519 AAAA... your@email.com" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
chmod 700 ~/.ssh

For cloud instances: Upload your public key through the cloud provider’s console:

• AWS: Key pairs in EC2 console
• GCP: Metadata → SSH Keys
• Azure: Reset password/SSH key in VM settings
• DigitalOcean: Settings → Security → SSH Keys

Fix 6: Check Server SSH Configuration

The server’s /etc/ssh/sshd_config controls authentication methods:

# On the server
sudo grep -E "PasswordAuthentication|PubkeyAuthentication|PermitRootLogin|AuthorizedKeysFile" /etc/ssh/sshd_config

Enable public key authentication:

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Enable password authentication (if needed):

PasswordAuthentication yes

Allow root login (not recommended for production):

PermitRootLogin yes

After changes, restart SSH:

sudo systemctl restart sshd

Warning: Be careful editing sshd_config while connected via SSH. A misconfiguration can lock you out. Always keep a second SSH session or console access open while testing changes.

Fix 7: Generate a New SSH Key Pair

If you do not have an SSH key or need a new one:

ssh-keygen -t ed25519 -C "your@email.com"

Follow the prompts. The key pair is saved to ~/.ssh/id_ed25519 (private) and ~/.ssh/id_ed25519.pub (public).

For systems that require RSA:

ssh-keygen -t rsa -b 4096 -C "your@email.com"

Then add the public key to the server (Fix 5).

For Git-specific SSH key issues, see Fix: git permission denied publickey.

Fix 8: Debug SSH Connection

Use verbose mode to see exactly what happens during connection:

ssh -vvv user@server.example.com

Key things to look for in the output:

debug1: Authentications that can continue: publickey,password

This shows which methods the server accepts.

debug1: Offering public key: /home/user/.ssh/id_ed25519
debug1: Authentications that can continue: publickey,password

The key was offered but not accepted — wrong key or not in authorized_keys.

debug1: No more authentication methods to try.

All methods exhausted — none worked.

Check the server logs:

sudo journalctl -u sshd -f
# or
sudo tail -f /var/log/auth.log

Server logs show why authentication failed (wrong key, permission issues, user not allowed).

Still Not Working?

Check for SELinux. On RHEL/CentOS, SELinux can block SSH even with correct permissions:

restorecon -R ~/.ssh

Check for firewall rules. If you cannot connect at all, it might be a network issue rather than authentication. See Fix: SSH connection timed out.

Check for AllowUsers/AllowGroups. sshd_config might restrict which users can SSH:

AllowUsers ubuntu admin
AllowGroups ssh-users

If your user is not in the list, authentication fails even with correct credentials.

Check for PAM issues. PAM (Pluggable Authentication Modules) might impose additional restrictions:

grep -r "pam" /etc/ssh/sshd_config

Check for fail2ban. If you tried too many failed logins, fail2ban might have banned your IP:

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip YOUR_IP

Try from a different network. Some networks (corporate, public WiFi) block SSH port 22. Try connecting on port 443 if the server supports it, or use a VPN.

For permission denied errors in bash scripts (not SSH), see Fix: bash permission denied.