How to fix "Permission denied (publickey)" over SSH

You try to log in, expecting a simple terminal prompt, and instead SSH slams the door with Permission denied (publickey).

Short version: Permission denied (publickey) means the server only accepts SSH key login, but it did not accept the key your computer offered. The fix is usually one of five things: use the right user, use the right private key, make sure the public key is on the server, fix file permissions, or confirm SSH key login is enabled for that account.

Why does SSH say "Permission denied (publickey)"?

SSH is the secure remote login tool that lets your computer talk to your server. A public key login works like a lock and key pair.

Your server keeps the public half of the key in a file called authorized_keys. Your computer keeps the private half. When you connect, SSH asks, “Can you prove you own the matching private key?”

The error string Permission denied (publickey) means that proof failed. It does not always mean your password is wrong. In many server setups, passwords are not accepted at all. The server is saying: “I only open for a known key, and I did not recognize yours.”

That can happen even when you are very close. One wrong username, one misplaced file, or one too-open permission setting can make a valid key look invalid.

What should you check first?

Start with the boring details. SSH problems often come from a tiny mismatch, like trying to open your front door with the garage key.

First, check the username. You are not just connecting to a machine; you are connecting as a specific user on that machine. root, ubuntu, debian, and your own app user are different identities. A key that works for one user may not work for another.

Second, check that you are connecting to the right server address. If you recently changed DNS, moved providers, or rebuilt the server, your terminal might be reaching a different machine than you think. If domain routing is part of the confusion, our guide on how to point a domain at your server explains the pieces in plain language.

Third, check which private key your SSH client is offering. Many people collect several keys over time: one for GitHub, one for a work laptop, one from an old server. SSH may be trying the wrong one unless you tell it which key belongs to this server.

A helpful way to think about it: the username is the name on the mailbox, the server address is the street address, and the private key is the physical key in your hand. All three must match.

What are the common causes of Permission denied (publickey)?

The most common cause is a missing public key. Your private key can be perfect, but the server still needs the matching public key in that user’s ~/.ssh/authorized_keys file. If the public key was pasted into the wrong user’s home directory, SSH will reject you.

Another common cause is file permissions. SSH is strict on purpose. If your .ssh folder or authorized_keys file is writable by too many people, SSH may ignore it. It is like a building refusing to trust a lock after discovering anyone in the hallway can change it.

You may also be using the wrong private key locally. This often happens after reinstalling your laptop, switching machines, or copying a project from someone else. The public key on the server must match the private key on the computer you are using now.

Sometimes the server’s SSH configuration blocks the login. For example, root login may be disabled, password login may be disabled, or a specific user may not be allowed. This is usually a good security choice, but it feels like a failure when you do not know which rule is stopping you.

Firewalls are a different problem. A firewall issue usually causes a timeout or “connection refused,” not Permission denied (publickey). If you suspect the server is not reachable at all, see our plain-English firewall guide: How to set up a firewall on your server.

How do you fix it without making things worse?

If you still have one working login session open, keep it open. Do not close your only open door while changing the lock.

Then confirm the user you intend to use. On the server, that user’s home folder should contain a .ssh directory, and inside it an authorized_keys file. The public key you want to use should be on its own line in that file.

Next, compare the key pair. The public key on the server should be the public half of the private key on your computer. Do not paste your private key onto the server. The private key is the secret half; treat it like a house key, not a name tag.

After that, check permissions. The user’s home folder, .ssh folder, and authorized_keys file should not be open for other users to edit. If SSH thinks other people can tamper with the key list, it may ignore the file entirely.

Finally, test in a separate terminal window before changing anything else. If the new login works, then you can safely close the old session. If it fails, your old session is still your safety rope.

If you are setting up a fresh server and this is one of your first roadblocks, it may help to step back and follow a fuller first-steps path. We cover that in I bought a server — now what?.

FAQ

**Does Permission denied (publickey) mean my server is down?** No. It usually means the server answered, but rejected your SSH key for that user.

Can I fix it with the root password? Only if password login and root login are enabled. Many servers disable one or both for safety.

Should I create a new SSH key? Only if you no longer have the correct private key, or you want to replace an old key. Otherwise, fix the mismatch first.

**Is it safe to paste my public key into authorized_keys?** Yes. The public key is meant to be shared. Never paste your private key there.

Why does one laptop work but another fails? Because the working laptop has the matching private key. The other laptop needs its own public key added to the server.

The shortcut

Server Manager helps you avoid the messy parts that usually create Permission denied (publickey) in the first place: the wrong user, a missing public key, unclear access rules, and a setup you cannot remember three months later.

The real benefit is that access stays legible. You can see what belongs to which server and which project, so you are not guessing whether an old key, an old username, or a half-finished setup is the reason SSH refuses you.

It also reduces the chance of locking yourself out while doing routine work. Instead of turning a small login issue into a late-night rescue job, you keep the server understandable enough to fix calmly.

What does a clean fix look like?

A clean fix is not just “I got in once.” It is knowing why you got in.

You know the correct username. You know which private key belongs to this server. The matching public key is in the right user’s authorized_keys file. The permissions are tight enough for SSH to trust them. And the setup is written down well enough that future-you is not solving the same puzzle again.

That is the win: SSH becomes a locked door you understand, not a locked door you fear.