Skip to content
Servers

How to Fix Permission Denied (publickey) on Ubuntu SSH

By Updated 8 min read
In this article10 sections

Permission denied (publickey) is the most common SSH error, and it is almost always a mismatch: the server does not have the public key you offered, or it refuses the key because a file has the wrong permissions. The error hides the reason on purpose, because a detailed message would help an attacker. The real reason is in two places: your client’s debug output, and the SSH service log on the server. This guide shows how to read both, then fixes each cause in order of how often it happens.

If you have not set up key-based login yet, start with how to set up SSH keys on Windows and Linux. This guide assumes a key exists and the server should accept it.

Step 1: Read the client’s debug output

Run the connection with verbose output. Add -v for one level, or -vvv for everything:

ssh -vvv [email protected]

Replace the user and address with the ones you are using. Look for these lines:

  • Offering public key: ... shows each key your client tried. If your intended key is not in the list, the client is not using it.
  • Server accepts key: ... means the server recognised the key. The error after this line points to a permission problem.
  • Authentications that can continue: publickey,password shows which methods the server allows. If publickey is missing, key login is disabled on the server.

Step 2: Read the server’s log

On Ubuntu 24.04, the SSH service is called ssh. Its log names the exact reason for a refusal, which the client never shows. Run this on the server, then try to connect again from the client while it is open:

sudo journalctl -u ssh -f

Press Ctrl+C to stop following the log. The lines you are looking for start with sshd[...], and they include messages such as:

  • Authentication refused: bad ownership or modes for directory /home/user means a directory or file has permissions that OpenSSH refuses. Go to Step 4.
  • User user from 198.51.100.7 not allowed because not listed in AllowUsers means the server restricts which users may log in. Check the AllowUsers line in the SSH configuration.
  • Failed publickey for user from ... means the key was offered and not found in the account’s authorised keys. Go to Step 3.
  • Invalid user name ... means the username does not exist on the server. Check the username in Step 3.

If the log shows no line for your attempt, the connection never reached the authentication stage. Check the host name, the port, and the firewall rules in Step 5.

Step 3: Confirm the key and the user

Most failures come from a key that is correct but installed for a different user. Check which user the key belongs to, on the server:

sudo cat /home/ubuntu/.ssh/authorized_keys

Replace ubuntu with the account you log in as. Compare the key line with the public key on your computer, the file that ends in .pub. The key text must match exactly, from the first word to the last. Keys are often pasted with a line break in the middle, and that breaks the match.

Two common traps:

  • The wrong username. Many Ubuntu cloud images create the account ubuntu, not your own name. Ask the provider which account the image uses, or check getent passwd on the server.
  • The root account. The default for PermitRootLogin is prohibit-password. That means root can log in with a key, but not with a password. If you are logging in as root with a password, the server refuses it before it checks anything else, and the error still says publickey.

To add a key to a user that has none, append the public key text to the file, as that user. Do not overwrite an existing file, or you will lock out the other keys:

cat ~/.ssh/id_ed25519.pub | ssh [email protected] "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

This works while password login is still allowed. Once you have confirmed the key works, you can disable password login (Step 6).

Step 4: Fix file permissions

OpenSSH refuses to read a key file if other users can change it. This check is the setting StrictModes, which is on by default. The rules are simple: the home directory must not be writable by anyone but its owner, the .ssh folder must be private to the user, and the key file must be readable and writable only by the user.

chmod go-w ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R "$USER":"$USER" ~/.ssh

Run these as the user who owns the account, on the server. Then check the modes:

ls -ld ~ ~/.ssh
ls -l ~/.ssh/authorized_keys

Expected: the home directory and the folder show no group or other write permission, the folder shows drwx------, and the key file shows -rw-------. A home directory that other users can write to is the most common cause of bad ownership or modes, and it often comes from copying files as root.

Step 5: Check the effective SSH settings

The configuration file is not the whole story, because included files and later lines can override earlier ones. Ask the SSH daemon for the settings it actually uses:

sudo sshd -T | grep -E "^(pubkeyauthentication|authorizedkeysfile|strictmodes|permitrootlogin|passwordauthentication|allowusers|port) "

What to expect:

  • pubkeyauthentication yes — if it says no, key login is off. Turn it on and reload SSH.
  • authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2 — the default. A different path means the file you edited is not the one SSH reads.
  • strictmodes yes — the default. Leave it on; turning it off hides a real security problem.
  • permitrootlogin prohibit-password — the default, and the safer choice on most servers.
  • allowusers — if the line is present, only the listed users may log in.

After any change, test the configuration before you reload it:

sudo sshd -t && sudo systemctl reload ssh

Expected: the test prints nothing, then the reload completes. If sshd -t reports an error, the reload does not run, and the existing connections keep working.

Step 6: Check the client side

If the server accepts your key, but your client offers the wrong one, the problem is on your computer. Three checks cover most cases:

  • Too many keys. The SSH agent offers every loaded key in turn, and the server disconnects after a few failures, before it reaches the right one. Limit the client to the key you name: 
    ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 [email protected]

    To make that permanent for one host, add it to ~/.ssh/config:

    Host sail
    HostName 203.0.113.10
    User ubuntu
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes
  • The wrong key type. Use an ed25519 key for new servers. Recent OpenSSH releases refuse some older RSA signature types, so an old RSA key can fail even when everything else is right.
  • The key is not loaded. If you protect the key with a passphrase, check the agent with ssh-add -l, and add the key with ssh-add ~/.ssh/id_ed25519.

Step 7: Turn off password login only after the key works

Disabling password login removes the most common attack path, but it also removes your fallback. Do it only after a new session has logged in with the key. Keep the first session open while you test, so you can still reach the server if a change goes wrong:

sudo nano /etc/ssh/sshd_config.d/50-keys-only.conf
PasswordAuthentication no
KbdInteractiveAuthentication no

Test and reload, then open a new terminal and log in with the key before you close anything:

sudo sshd -t && sudo systemctl reload ssh
sudo sshd -T | grep -E "^passwordauthentication "

Expected: passwordauthentication no. If the new terminal cannot connect, use the first session to revert the file and reload.

When you are locked out

If no session is open and the key no longer works, you need console access. A provider’s web console, or the out-of-band management interface of a dedicated server, lets you log in without SSH. The steps for a dedicated server are in how to recover a dedicated server after an SSH lockout. Once you are in, use Step 2 to read the log, and Step 4 to fix permissions.

Common mistakes

  • Fixing the wrong account. The key may be correct for ubuntu while you log in as root, or the reverse.
  • Editing a copy of authorized_keys. SSH reads the file in the account’s home directory only.
  • Making the home directory writable for convenience. It breaks key login for every account on the server.
  • Restarting instead of reloading after a change. A reload applies the change and keeps your session. Test with sshd -t first.
  • Turning off StrictModes. It is the check that protects keys from being read by other users. Fix the permissions instead.

Changing SSH settings is the step most likely to lock you out, so allow the SSH port in the firewall first, as shown in how to set up a UFW firewall on Ubuntu. Then check the rest of the host with how to audit a new Ubuntu VPS for security.

Frequently asked questions

Why does the server say publickey and not what went wrong?

The client message is intentionally generic. The server log has the reason, so read it with journalctl.

Can I use a key from another computer?

Yes. Add its public key to authorized_keys. Each computer should have its own key, so you can remove one without affecting the others.

Does this also apply to Windows?

Yes. The same server checks apply. On Windows, the client’s .ssh folder and its key file must also be private, and the SSH agent must hold the right key. The steps are in the Windows part of the SSH key guide.

Is it safe to leave password login on?

It is safer to turn it off once keys work, because password login is the target of most automated guessing attacks. Use a strong password if you keep it on, and rely on fail2ban for repeated attempts.

Read the server log first. It names the reason in one line: the wrong key, the wrong account, or a file that other users can change. Fix that cause, test with sshd -t, and keep a session open until a new login succeeds.

Share this guide

Keep exploring