Fix "Permission denied (publickey)" When Connecting via SSH

The Error

$ ssh user@192.168.1.100
user@192.168.1.100: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

Or the short variant common on cloud servers:

Permission denied (publickey).

SSH rejected your connection. The server listed every auth method it supports — and none of them worked. Annoying, but fixable. It almost always comes down to one of five root causes.

Root Causes

• Your private key doesn't match any public key in the server's ~/.ssh/authorized_keys
• File permissions on ~/.ssh/ or authorized_keys are too loose — SSH refuses to use them
• The SSH agent doesn't have your key loaded
• You're connecting with the wrong username (common with EC2, DigitalOcean, etc.)
• The key file path is wrong or you forgot to pass -i

Step 1: Run SSH in Verbose Mode First

Don't guess. Make SSH tell you exactly what it's trying:

ssh -vvv user@your-server.com

Scroll through the output and look for lines like:

debug1: Offering public key: /home/you/.ssh/id_rsa RSA ...
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.

"Offering public key" followed by "No more authentication methods" means the server rejected that specific key. No "Offering" line at all? The client isn't finding a key to try.

Fix 1: Verify the Public Key Is in authorized_keys

The most common cause. Grab your public key from the local machine:

cat ~/.ssh/id_rsa.pub
# or
cat ~/.ssh/id_ed25519.pub

Then on the server, check if it's listed:

cat ~/.ssh/authorized_keys

Not there? Add it:

# From your local machine:
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server.com

# Or manually — append the key:
echo "your-public-key-content" >> ~/.ssh/authorized_keys

One thing to double-check: each key must be a single unbroken line. Any line break inside the key and SSH won't recognize it.

Fix 2: Fix SSH File Permissions

SSH will silently ignore keys if permissions are too open. No warning, no helpful message — it just refuses. Easy to miss, very easy to fix.

On the server:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

On your local machine, fix the private key:

chmod 600 ~/.ssh/id_rsa
# or
chmod 600 ~/.ssh/id_ed25519

The rules SSH enforces:

• ~/.ssh/ directory — must be 700 (owner only)
• authorized_keys — must be 600 or 640 at most
• Private key files — must be 600 (world-readable = SSH refuses to use them)

Tip: If you can never remember which chmod number means what, the Unix Permissions Calculator at ToolCraft lets you set permissions visually and shows the equivalent chmod number. Genuinely useful when you keep second-guessing whether 640 or 644 is right.

Fix 3: Specify the Correct Key with -i

Multiple keys on your system? SSH picks one automatically — and it might pick the wrong one. Be explicit:

ssh -i ~/.ssh/my-specific-key user@your-server.com

For AWS EC2, use the .pem file you downloaded when the instance was created:

ssh -i ~/Downloads/my-ec2-key.pem ec2-user@your-ec2-ip

Also watch the username. EC2 Amazon Linux uses ec2-user, Ubuntu uses ubuntu, Debian uses admin. Wrong username = permission denied even with the right key.

Fix 4: Add Key to SSH Agent

The SSH agent caches your decrypted key in memory so you don't re-enter the passphrase on every connection. If the agent isn't running or your key isn't loaded, it may not get offered during authentication. Start the agent and add your key:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Check what's currently loaded:

ssh-add -l

"The agent has no identities" means nothing is loaded. Run ssh-add and enter your passphrase.

Fix 5: Check authorized_keys on the Server (SELinux / Wrong Owner)

CentOS and RHEL servers run SELinux, which enforces file context on top of standard Unix permissions. Correct chmod values aren't always enough. Check the file context:

ls -laZ ~/.ssh/authorized_keys

Context looks wrong? Restore it:

restorecon -Rv ~/.ssh

While you're there, verify ~/.ssh is owned by the right user:

ls -la ~ | grep .ssh
# Should show: drwx------ 2 youruser youruser

Root ownership on ~/.ssh is surprisingly common after running sudo commands. Fix it:

sudo chown -R youruser:youruser ~/.ssh

Fix 6: Check sshd Config on the Server

Worth checking last — occasionally the server itself is configured to reject public key auth entirely:

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

You want to see:

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

If PubkeyAuthentication is set to no, change it and restart sshd:

sudo systemctl restart sshd

Verify the Fix

After any change, test with verbose mode:

ssh -v user@your-server.com

Successful auth looks like:

debug1: Authentication succeeded (publickey).

Still failing? Work through the fixes in order. Permission issues and wrong keys account for about 80% of cases — chances are you'll hit the solution by Fix 2 or Fix 3.

Prevention

• Generate keys with ssh-keygen -t ed25519 — Ed25519 is significantly faster than RSA-2048 for signing operations and considered more resistant to future attacks
• Use ssh-copy-id to deploy keys instead of manual copy-paste — it sets the right permissions automatically
• Store connection details in ~/.ssh/config so you never mix up usernames or key paths:

Host myserver
  HostName 192.168.1.100
  User ubuntu
  IdentityFile ~/.ssh/id_ed25519

• Back up your ~/.ssh/ directory. Losing a private key means losing access to every server it's registered on — there's no recovery path
• Rotate SSH keys periodically and always protect them with a strong passphrase. The password generator at ToolCraft is handy here — SSH key passphrases need to be both strong and something you can actually type from memory