git: Permission denied (publickey)

Fix "Permission denied (publickey)": run ssh -vT git@github.com, ssh-add your key, chmod 600 it, and add the public key to your account. Covers multiple keys.

easy fix·6 min read·4 causes

By Vishvesh Patel·DevOps Engineer·Updated 16 September 2026

Run these in order. Each one tells you what its output means before you change anything.

• Ask the server what it thinks of you

'Hi <username>!' means your key is fine and the real problem is the remote URL or your access to that repository. 'Permission denied (publickey)' means no key was accepted. Keep going.

• See which keys are actually being offered

If nothing is offered, the agent is empty or your key is not where SSH looks. ssh-add -l lists what is loaded and ssh-add ~/.ssh/id_ed25519 loads it.

• If a key is offered and refused, it is not on the account

Compare that fingerprint against the keys listed in your GitHub or GitLab settings. If it is not there, cat the .pub file and add it.

• Fix permissions, which SSH enforces silently

SSH ignores a private key that is group- or world-readable and does not tell you why. This alone explains a surprising share of these failures.

If the steps above did not settle it, these are the causes in the order they are usually responsible. Each section explains why it happens and how to confirm it.

This is an SSH error, not a Git one. Git asked SSH to open a connection, SSH offered whatever keys it had, the server rejected all of them, and Git reported the failure it was handed.

That distinction matters because it tells you where to look: nothing about your repository, your branch or your remote URL is relevant yet.

That message is success. GitHub has no shell, so this is as far as it goes. If you see it, SSH works and the problem is elsewhere.

If it fails, get the detail:

Two lines tell you nearly everything. Offering public key shows which keys SSH tried, if nothing is offered, that is your answer. type -1 means the file named does not exist.

The most common case, and the debug output makes it obvious: no Offering public key line at all.

If there is no key, create one:

Then add the public key, the .pub file, to your account. Never the private one:

SSH only offers default filenames automatically (id_ed25519, id_ecdsa, id_rsa). A key named github_key is not tried unless you tell SSH about it. See the config section below.

SSH refuses to use a private key other accounts can read, and ignores it silently as far as Git is concerned. You just see Permission denied (publickey).

This appears most often after copying keys from a backup, another machine, or a mounted volume, all of which lose the original modes.

On macOS, persist it across reboots:

And in ~/.ssh/config so it happens automatically:

On Linux, the agent is usually started by your session. If ssh-add -l reports Could not open a connection to your authentication agent, start one:

The key exists, has correct permissions, is loaded, and the server still rejects it. Compare fingerprints:

That fingerprint must appear in your account's SSH keys list. If it does not, the public key was never added, or was added to a different account, which is easy on a machine with both personal and work identities, and produces exactly this error against one host while working against another.

Testing both quickly shows whether the key works somewhere.

The clean solution is a host alias per identity in ~/.ssh/config:

IdentitiesOnly yes is the important line. Without it SSH offers every key it knows about in turn, and the server accepts the first valid one, which may be the wrong account entirely. That produces the confusing situation where a push "works" but commits arrive under the wrong identity, or where the server rejects you after too many failed offerings.

A mismatched pair like that fetches over SSH and pushes over HTTPS. If you meant SSH throughout:

Note that Permission denied (publickey) only ever comes from the SSH form. An HTTPS remote fails with a credential prompt or a 403 instead, which is a different problem entirely.

Two less common causes worth knowing.

The repository does not exist, or you lack access. The message deliberately conflates "no such repository" with "no permission", so a private repository you are not a member of looks identical to an authentication failure. If ssh -T succeeds but git clone fails, this is why.

The organisation requires SSH certificate authority or key expiry. Some organisations expire keys or require SAML SSO authorisation per key. In that case the key is listed on your account and still rejected until authorised.

What does "Permission denied (publickey)" actually mean?

That the SSH server rejected every key your client offered. It is an SSH failure that Git is merely reporting, so nothing about your repository, branch or Git configuration is involved yet. Run ssh -T git@github.com to test SSH on its own, if that succeeds, authentication is fine and the problem is repository access instead. ssh -vT shows which keys were offered, which is usually enough to identify the cause in one command.

Why does SSH ignore my key even though it exists?

Most likely its file permissions are too permissive. SSH refuses to use a private key that other accounts on the machine could read, and skips it, so from Git's perspective no key was offered at all. Run chmod 600 ~/.ssh/id_ed25519 and chmod 700 ~/.ssh. This appears most often after copying keys from a backup, another machine or a mounted drive, since all of those lose the original file modes.

Why isn't my key with a custom filename being used?

Because SSH only tries default names automatically, id_ed25519, id_ecdsa, id_rsa. A key called github_work is invisible to it unless you either add it to the agent with ssh-add or name it in ~/.ssh/config with an IdentityFile entry. The config approach is better, since it survives reboots and documents which key belongs to which host.

How do I use different SSH keys for work and personal GitHub accounts?

Define a host alias per identity in ~/.ssh/config, each with its own IdentityFile and IdentitiesOnly yes, then clone using the alias, git@github-work:acme/repo.git. The IdentitiesOnly yes line matters: without it SSH offers every key in turn and the server accepts the first valid one, which may authenticate you as the wrong account, so commits land under the wrong identity or the server rejects you after too many attempts.

How do I check whether my key is on my GitHub account?

ssh-keygen -lf ~/.ssh/id_ed25519.pub prints the key's fingerprint, and that exact string should appear in your account's SSH keys settings. If it is absent, the public key was never added, or was added to a different account, which is easy to do on a machine holding both work and personal identities and produces this error against one host while another works fine.

SSH authenticates successfully but git clone still fails. Why?

Because the message conflates authentication with authorisation. Once ssh -T succeeds your key is fine, so a failing clone means the repository does not exist at that path, or your account cannot see it. A private repository you are not a member of looks identical to an authentication failure by design, so as not to reveal which repositories exist. Check the path carefully, and whether your key needs SAML SSO authorisation for that organisation.

Free, comprehensive DevOps tutorials and learning roadmaps. Master Docker, Kubernetes, CI/CD, and more.

Get notified about new tutorials and features.

• Roadmaps

• Interview Prep

• Certifications

• Company

© 2026 DevOpsLesson. All rights reserved.