Error message

`Permission denied (publickey)`

SSH rejected your login because no key you offered was accepted by the server.

Quick diagnosis

Start here. This one command usually tells you which of the causes below you are dealing with:

$ ssh -v user@server

Run this first, always. The verbose output names every key your client offered and how the server replied — it turns guesswork into a two-line diagnosis.

Causes, ordered by how often they are the culprit

1 Your public key is not on the server (most common)

The server keeps authorised keys in ~/.ssh/authorized_keys for the user you are logging in as. If yours is not in that file, the server has nothing to match against.

Check

$ ssh -v user@server 2>&1 | grep -i "offering\|authenticat"

Fix

$ ssh-copy-id user@server

ssh-copy-id needs another way in (a password, or console access). If password login is disabled and you have no key that works, you need out-of-band access: your provider's web console, a rescue mode, or an administrator.

2 Wrong permissions on your key or on ~/.ssh

SSH deliberately refuses private keys that other users can read — a key anyone can copy is not a secret. This bites constantly after restoring a backup, cloning a repo of dotfiles, or copying keys from Windows.

Check

$ ls -la ~/.ssh

Fix

$ chmod 700 ~/.ssh && chmod 600 ~/.ssh/id_ed25519 && chmod 644 ~/.ssh/id_ed25519.pub

The same rule applies on the server side: ~/.ssh must be 700 and authorized_keys 600, owned by the user logging in. A world-writable home directory also causes rejection.

3 The client is offering the wrong key

If you have several keys, SSH offers them in its own order and the server may refuse them all before reaching the right one. Servers also limit how many attempts they accept.

Check

$ ssh -v user@server 2>&1 | grep "Offering public key"

Fix

$ ssh -i ~/.ssh/the_right_key user@server

Once it works, make it permanent in ~/.ssh/config so you never think about it again — see the prevention section below.

4 Wrong username

Keys are authorised per user. Logging in as the wrong one means the server looks in a different authorized_keys and finds nothing. Cloud images each have their own default: ubuntu on Ubuntu images, ec2-user or admin on Amazon Linux and Debian, root on many bare VPS providers.

Check

$ ssh -v ubuntu@server   # try the image default

Fix

$ ssh correct-user@server

5 The key is not loaded in the agent

If your key has a passphrase and you rely on ssh-agent, an agent that has been restarted (or a fresh login session) holds no keys.

Check

$ ssh-add -l

Fix

$ ssh-add ~/.ssh/id_ed25519

"The agent has no identities" confirms this cause.

6 The server refuses your key type

Older servers may not support ed25519; very new ones reject legacy ssh-rsa with SHA-1. The verbose log shows the negotiated algorithms.

Check

$ ssh -v user@server 2>&1 | grep -i "no mutual\|type"

Fix

$ ssh-keygen -t ed25519   # or -t rsa -b 4096 for older servers

How to stop it happening again

Define each server once in ~/.ssh/config with Host, HostName, User and IdentityFile. From then on it is just `ssh web1`, with the right key and user guaranteed.
Keep permissions correct by habit: 700 on ~/.ssh, 600 on private keys, 644 on public keys.
Before disabling password authentication on a server, open a second terminal and confirm key login works. Locking yourself out of a remote machine is a bad afternoon.
On a VPS, know where your provider's web console is before you need it. That is your way back in.

Frequently asked questions

Why does it say publickey when I am typing a password?

It does not ask for one: the server has PasswordAuthentication disabled, so keys are the only accepted method. The error names the only method that was tried.

I can log in from my laptop but not from another machine — why?

Keys live on machines, not accounts. The second machine has a different key (or none). Either copy the key across carefully, or generate a new pair there and add its public half to the server.

What exactly do the permissions need to be?

Client: ~/.ssh 700, private key 600, public key 644. Server: ~/.ssh 700, authorized_keys 600, and the home directory itself must not be writable by group or others.

Does this error mean I have been hacked?

No. It means authentication was refused. Repeated failures from unknown addresses in the server logs are just internet background noise — every public SSH port sees it constantly.

Commands involved

ssh

Log into remote machines, run remote commands, use keys instead of passwords, and tunnel ports.

chmod

Change file permissions with numeric (755, 644) and symbolic (u+x) modes — clearly explained.

scp

The quickest way to move a file to or from a remote machine.

Concepts behind this error: SSH key · File permissions

How to do it properly

Copy files to or from a remote server

Move files between machines with scp and rsync, over the same encrypted connection.

Connect to a Linux server with SSH

Connect securely to a remote Linux host using username, hostname, port and SSH key.

Other errors

bash: command: command not found

The shell searched every directory in your PATH and found no executable with that name.

No such file or directory

The path you gave does not resolve — but often the missing part is not the one you think.

Permission denied

The path resolves fine — the system simply will not let you do that with it.

No space left on device

A filesystem is full — confirm which one, and whether you ran out of bytes or inodes.