SSH: Permission denied (publickey)

Hi, it's BlueByte. "Permission denied (publickey)" feels like a wall, but SSH will tell you exactly why if you ask it verbosely — you do not have to guess. Let's read what your client actually offered and what the server said, then fix the one thing that failed.

What the message means

A connection ends before you get a shell:

git@github.com: Permission denied (publickey).

The server offered public-key authentication, none of the keys your client sent were accepted, and there was no password fallback. Which of those failed decides the fix — so ask SSH rather than guessing.

The three things that usually fail

Almost every case is one of these:

• Your key is not loaded into the agent, or the key file is not where SSH looks.
• The client is sending a different key than the one the server trusts — common when you have several keys and the agent offers the wrong one first.
• The server refuses the key over permissions — your ~/.ssh directory or the private key file is readable by others, and SSH ignores keys with loose permissions.

Ask SSH which one it is

Run the connection verbosely and read which keys it offers and how the server responds:

ssh -vT git@github.com

Look for Offering public key: ... followed by the server's answer. No key offered means it is not loaded; a key offered and rejected means the wrong key or a server that does not trust it; a Permissions ... are too open warning means the file mode is the problem. The verbose trace removes the guesswork.

Fix the one that failed

1. No key offered — add yours to the agent:

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

2. Wrong key offered — pin the right one per host:

# ~/.ssh/config
Host github.com
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes

3. Rejected over permissions — tighten them; SSH ignores keys others can read:

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

A real case: the agent offered an old key

You clone over SSH and get Permission denied (publickey). ssh -vT git@github.com shows it offering id_rsa (an old key) and the server rejecting it, never reaching your newer id_ed25519. So it is key selection, not a missing key. You add a Host github.com block with IdentityFile ~/.ssh/id_ed25519 and IdentitiesOnly yes, re-run ssh -vT, and this time it offers only the ed25519 key, which the server accepts with "successfully authenticated". The clone works.

Confirm the key is accepted

Test the authentication path without opening a shell:

ssh -T git@github.com

A greeting like Hi <user>! You've successfully authenticated (even though it then closes the connection) means the key is accepted.

Keep it from recurring

Keep IdentitiesOnly yes in your SSH config so the agent does not throw every key at a server and trip a limit on attempts, register each new machine's public key with the service once, and keep ~/.ssh permissions tight so a synced dotfiles setup never loosens them.

How this differs from a connection or host-key error

Permission denied (publickey) is authentication failing after a connection. Connection refused or Connection timed out are earlier — the server is unreachable or nothing is listening on port 22 — and Host key verification failed is a changed server key, a different problem entirely. When you hit the publickey error, run ssh -vT first; the answer is almost always in that trace.