Introduction

Permission denied (publickey) from GitHub means the SSH connection reached GitHub, but GitHub did not accept any key your machine offered. The fix is usually to verify that you have the right private key locally, the matching public key registered in GitHub, and an SSH configuration that actually uses that key.

What the Error Really Means

This is not a Git repository permission message in the abstract. It is an SSH authentication failure. GitHub accepts SSH access only when the presented private key matches a public key attached to your account or organization access model.

That means the problem usually lives in one of these places:

• no local SSH key
• correct key exists but is not loaded
• wrong key is offered first
• public key was never added to GitHub
• the remote URL is SSH but your setup only works for HTTPS

First Checks

See what keys the agent currently knows:

ssh-add -l

If you get "The agent has no identities," start the agent and add a key:

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

Then test GitHub directly:

ssh -T [email protected]

If authentication works, Git operations over SSH should work too.

Create and Register a Key

If you do not have a key yet:

ssh-keygen -t ed25519 -C "[email protected]"

Then copy the public key:

cat ~/.ssh/id_ed25519.pub

Paste that into GitHub under SSH keys. The private key stays on your machine; only the .pub content goes to GitHub.

Check Your Remote URL

Sometimes the key is fine, but the repository remote is not what you think:

git remote -v

An SSH remote looks like this:

[email protected]:owner/repo.git

If your remote is HTTPS, SSH keys are irrelevant for that remote.

Use ~/.ssh/config When Multiple Keys Exist

If you have several identities, tell SSH which one to use:

1Host github.com
2  HostName github.com
3  User git
4  IdentityFile ~/.ssh/id_ed25519
5  IdentitiesOnly yes

This prevents SSH from offering the wrong key first and getting rejected.

Debugging with Verbose Output

When the problem is stubborn, use verbose SSH output:

ssh -vT [email protected]

That shows which keys are being offered and whether GitHub accepts any of them. It is usually the fastest way to see whether the failure is in key loading, key selection, or account registration.

This matters especially on machines with several identities, because the agent may happily offer a key that works for another server but has nothing to do with GitHub. Verbose output makes that mistake obvious.

It also shows whether the correct config file is even being read.

On multi-account machines, that extra visibility is often what finally reveals that the wrong identity file is being applied to github.com.

Common Pitfalls

• Adding the private key to GitHub instead of the public key.
• Forgetting to load the private key into the SSH agent.
• Having multiple keys and using the wrong one.
• Testing the key successfully but cloning with an HTTPS remote.
• Assuming the problem is Git-specific when it is really SSH authentication.

Summary

• 'Permission denied (publickey) is an SSH key-authentication failure.'
• Verify the local private key, the agent, and the GitHub-side public key.
• Test with ssh -T [email protected].
• Use ~/.ssh/config when multiple keys exist.
• Check the remote URL so you know whether you are using SSH at all.