Permission Denied (publickey): How to Fix the Most Common SSH Error

You run ssh user@server, hit Enter, and get this:

user@server: Permission denied (publickey).

It's the most common SSH error there is — and one of the most frustrating, because the message tells you almost nothing about what's actually wrong. The good news: it's nearly always one of a handful of causes, and every one of them is fixable in a couple of minutes.

This guide walks through each cause in the order you should check it.

What the error actually means

Permission denied (publickey) means the server rejected your connection because it couldn't authenticate you with a public key — and public key is the only method it accepts (password login is disabled).

So the problem is one of three things:

• Your SSH client never sent a key
• It sent the wrong key
• The key it sent isn't trusted by the server

Let's rule them out one at a time.

Step 1: Run SSH in verbose mode

Before changing anything, get more information. Add -v (or -vvv for maximum detail):

ssh -v user@server

Look for lines like these:

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

If you see Offering public key followed by a rejection, the server got your key but doesn't trust it — jump to Step 4. If there's no Offering line at all, your client never found a key to send — start at Step 2.

Step 2: Make sure you actually have a key

Check what's in your ~/.ssh folder:

ls -la ~/.ssh

You're looking for a key pair — id_ed25519 and id_ed25519.pub, or id_rsa and id_rsa.pub. If there's nothing there, generate one:

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

Then load it into the agent:

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

Step 3: Tell SSH which key to use

If you have a key but SSH isn't offering it, point to it explicitly:

ssh -i ~/.ssh/id_ed25519 user@server

If that works, make it permanent in ~/.ssh/config:

Host server
  HostName server.example.com
  User deploy
  IdentityFile ~/.ssh/id_ed25519

Step 4: Fix file permissions (the most common cause)

SSH is deliberately paranoid. If your key files are readable by anyone other than you, it silently refuses to use them. Fix every permission at once — on your Mac:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

And on the server, where the home directory itself also matters:

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

If ~ or ~/.ssh on the server is group- or world-writable, SSH ignores authorized_keys entirely — and you get Permission denied (publickey).

Step 5: Make sure your public key is on the server

The server only trusts keys listed in ~/.ssh/authorized_keys for the user you're logging in as. The easiest way to add yours:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server

If password login is disabled and ssh-copy-id can't get in, use your host's web console to open a session, then paste the contents of your .pub file into ~/.ssh/authorized_keys by hand. A truncated or line-wrapped paste is a common cause of failure — the key has to sit on a single line.

Step 6: Check you're using the right username

This one trips up a lot of people. The username is server-specific:

• AWS EC2 Ubuntu → ubuntu
• AWS EC2 Amazon Linux → ec2-user
• A fresh DigitalOcean or Hetzner server → root
• GitHub → always git, never your GitHub username

ssh git@github.com        # correct
ssh yourname@github.com   # Permission denied (publickey)

Step 7: The wrong-key problem

If you have many keys loaded, SSH tries them one by one — and servers often cut you off with Too many authentication failures before it reaches the right one.

See what's loaded in the agent:

ssh-add -l

Force SSH to use only the correct key:

ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes user@server

Or set it in your config:

Host server
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes

The quick checklist

• Run ssh -v to see exactly where it fails
• A key pair exists in ~/.ssh
• chmod 700 ~/.ssh and chmod 600 on the private key — locally and on the server
• The server's home directory isn't world-writable
• Your public key is in the server's authorized_keys, on a single line
• You're using the correct username for that host
• IdentitiesOnly yes if you have several keys

Skip the guesswork

Most Permission denied (publickey) errors come down to permissions, the wrong key, or the wrong username — boring mistakes that are easy to make by hand.

A connection manager like Pluto Door handles the mechanical parts for you: it stores each connection's key, username, and port together, keeps credentials in the macOS Keychain with the right permissions, and surfaces the real SSH error instead of a cryptic one-liner. You set a connection up once, and it just works after that.

Whatever client you use, work through the steps above in order — the fix is almost always in the first four.