Fix: Permission denied (publickey)

You run ssh, git push or git clone and get:

[email protected]: Permission denied (publickey).

This means the server only accepts key-based login, and none of the keys your client offered matched a public key in that user’s authorized_keys. The word in parentheses is the list of login methods the server still allows. Nothing is wrong with the network: the connection worked, the authentication did not.

Step 1: see what SSH actually tried

Verbose mode prints each key the client offers and how the server responded.

ssh -v [email protected]
# For Git hosts:
ssh -vT [email protected]

Look for lines such as Offering public key: /home/ana/.ssh/id_ed25519 and Authentications that can continue: publickey. If no key is offered at all, your client cannot find one. If a key is offered and then the next method is tried, the server does not know that key.

Step 2: check the usual causes

1. Wrong username. Keys are stored per user on the server. ssh server uses your local username unless you add user@ or set User in ~/.ssh/config. For Git hosts the user is always git, as in [email protected].
2. The public key is not on the server. Install it with ssh-copy-id -i ~/.ssh/id_ed25519.pub user@host (needs another way in, such as a password or a console), or add the .pub contents to your Git host account.
3. The client offers the wrong key. SSH tries default names such as id_ed25519 and id_rsa, plus whatever is loaded in the agent. Point it at the right file with ssh -i ~/.ssh/work_key user@host, or permanently with IdentityFile and IdentitiesOnly yes in ~/.ssh/config.
4. The key is not loaded in the agent. Run ssh-add -l to list loaded keys and ssh-add ~/.ssh/id_ed25519 to add yours.
5. Permissions are too open on the server. With the default StrictModes setting, the SSH server ignores authorized_keys if the home folder, ~/.ssh or the file itself is writable by others.

Step 3: fix permissions

On your own machine, the private key must be readable only by you, or SSH will refuse to use it and warn about an “UNPROTECTED PRIVATE KEY FILE”:

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

On the server (as the target user):

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod go-w ~

Step 4: check the server side

If you administer the server, its log usually says exactly why the key was rejected. Depending on the distribution, look at journalctl -u ssh or journalctl -u sshd, or the file /var/log/auth.log. Also confirm the line in authorized_keys is one unbroken line: copying from a terminal sometimes inserts line breaks.

A Git-specific variant

If git push fails but your remote URL starts with git@, the same steps apply. If you would rather use a token over HTTPS, switch the remote with git remote set-url origin https://.... Either way, test the SSH side alone with ssh -T [email protected] before debugging Git itself.