“Permission denied (publickey)”: fixing SSH and git key errors

The server turned down every key your computer offered. Usually the right key exists but wasn’t offered, was offered to the wrong user, or is sitting in a file the server refuses to read.

What the message means

user@host: Permission denied (publickey).
fatal: Could not read from remote repository.

SSH tried to log you in with a key pair. Your computer offered one or more public keys; the server checked each against the list of allowed keys for that account and accepted none. The word in brackets is the list of login methods the server still allows, so (publickey) also tells you password login is switched off. Typing a password again won’t help.

Step 1: see what ssh is actually doing

ssh -v [email protected]          # a server
ssh -vT [email protected]              # a git host (same idea for GitLab, Bitbucket)

Read the lines near the end:

Fixes on your computer

• Wrong user name. Git hosts always use the user git ([email protected]), never your account name. Servers often use ubuntu, ec2-user, root or a named account; check which one your key was added to.
• No key yet. Create one: ssh-keygen -t ed25519 -C "laptop", then copy the .pub file’s single line to the server or git host.
• Key not loaded. ssh-add -l lists what the agent holds; ssh-add ~/.ssh/id_ed25519 adds it. On macOS add --apple-use-keychain to keep it after reboots. On Windows, start the OpenSSH Authentication Agent service first.
• Key has a custom name. ssh only tries default names (id_ed25519, id_rsa, …). Name it in ~/.ssh/config:

Host github.com
    User git
    IdentityFile ~/.ssh/work_ed25519
    IdentitiesOnly yes

Host myserver
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/deploy_ed25519

IdentitiesOnly yes stops ssh offering every key it knows. Servers give up after a handful of attempts (Too many authentication failures), so a full agent can lock you out before the right key is tried.

Fixes on the server

• Public key missing. Add the whole .pub line to ~/.ssh/authorized_keys of the account you log in as (ssh-copy-id deploy@host does it for you while password login still works, or use your cloud provider’s console). One key per line, no line breaks inside it.
• Permissions too loose. With the default StrictModes yes, sshd ignores authorized_keys if the home folder, ~/.ssh or the file is writable by others: chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys, home folder no looser than 755, all owned by that user. The chmod guide explains the numbers.
• Look at the server log if you still have another way in: journalctl -u ssh -n 50 (Debian/Ubuntu; sshd elsewhere) or /var/log/auth.log names the exact reason, such as Authentication refused: bad ownership or modes.
• Old RSA keys. Recent OpenSSH refuses SHA-1 RSA signatures. A modern client and an ed25519 key avoid it.

Git host checklist

• The key is added to your account’s SSH keys, not only as a read-only deploy key on another repository.
• ssh -T [email protected] greets you by the account name you expect. If it names another account, a different key is being offered first: use IdentitiesOnly as above.
• The remote really is SSH: git remote -v shows git@host:owner/repo.git. An https:// remote never uses your key.
• Comparing two public keys? Paste both into the hash generator or compare ssh-keygen -lf key.pub fingerprints with the ones your host shows.

Cannot even reach the host (Connection timed out)? See ssh Connection timed out port 22. Scary host-key warning instead of a publickey denial? See REMOTE HOST IDENTIFICATION HAS CHANGED.

Related

ssh Connection refused port 22 · fatal: Authentication failed for (Git HTTPS)

Questions

Published 4 November 2026.