SSH Permission Denied (publickey): Causes and Fixes

The “Permission denied (publickey)” error occurs when the SSH server rejects your connection because it cannot verify your identity using public key authentication.

user@remote_host: Permission denied (publickey).

This is one of the most common SSH errors. Seeing it is actually a good sign for the network path, because the server answered and reached the authentication stage; a connection that stops earlier with connection refused is a different problem. In this guide, we will go through the most frequent causes and how to fix them.

Reading the Error Message #

The methods in parentheses are the ones the server still accepts for this login. The list does not tell you why the key failed, but it shows how the server is configured:

• (publickey) - Only key authentication is allowed. Password login is disabled, which is the default on many cloud images.
• (publickey,password) - The server also accepts passwords. Both the key and the password failed, or the client never asked for a password (for example, in a script or with BatchMode=yes).
• (publickey,password,keyboard-interactive) - Keyboard-interactive login is enabled as well. It is used for PAM prompts and one-time codes.
• (publickey,gssapi-keyex,gssapi-with-mic) - The server also accepts Kerberos (GSSAPI) logins. Fedora and RHEL servers enable it by default.

If publickey is missing from the list, key authentication is disabled for that user on the server. No change on the client will fix that.

Debugging the Connection #

Before trying specific fixes, run SSH in verbose mode to see exactly where the authentication fails:

ssh -v user@remote_host

For even more detail, use -vv or -vvv:

ssh -vvv user@remote_host

When the server accepts your key, the output includes a Server accepts key line:

debug1: Offering public key: /home/user/.ssh/id_ed25519 ED25519 SHA256:rIb41Chw7tL4ex2qmP85DZ9eFTStt9wXyI8jzIpi4nw
debug1: Server accepts key: /home/user/.ssh/id_ed25519 ED25519 SHA256:rIb41Chw7tL4ex2qmP85DZ9eFTStt9wXyI8jzIpi4nw
Authenticated to remote_host ([192.168.1.10]:22) using "publickey".

When the key is rejected, the output looks like this:

debug1: Offering public key: /home/user/.ssh/id_ed25519 ED25519 SHA256:rIb41Chw7tL4ex2qmP85DZ9eFTStt9wXyI8jzIpi4nw
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/user/.ssh/id_ed25519_sk
debug1: No more authentication methods to try.
user@remote_host: Permission denied (publickey).

The client offered id_ed25519, and the server answered with the same list of allowed methods. The client then checked the last default key file and gave up.

The verbose output tells you which keys are being tried and where the process fails. If your key does not appear in any Offering public key line, the client never sent it. This usually means the key has a non-default name, and you need to point SSH to it with -i or IdentityFile.

Common Causes and Fixes #

1. Public Key Not on the Remote Server #

The most common cause is that your public key is not in the remote server’s ~/.ssh/authorized_keys file.

Copy your public key to the server:

ssh-copy-id user@remote_host

If ssh-copy-id is not available, copy it manually:

cat ~/.ssh/id_ed25519.pub | ssh user@remote_host "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

For more details, see our guide on how to copy SSH keys with ssh-copy-id .

2. Wrong File Permissions #

SSH is strict about file permissions. If the permissions are too open, the SSH server will reject the key.

On the remote server, set the correct permissions:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

On the local machine, set the correct permissions on your private key:

chmod 600 ~/.ssh/id_ed25519

The SSH server will also reject keys if the home directory is writable by others. Remove the write permission for group and others:

chmod go-w ~

Do not use chmod 755 ~ for this. Ubuntu creates home directories with mode 750, and 755 makes your files readable by every user on the system.

The files must also belong to the user you log in as. If you created ~/.ssh or authorized_keys with sudo, root owns them, and the server refuses to use them. Fix the ownership on the remote server:

sudo chown -R user:user /home/user/.ssh

These checks are enforced by the StrictModes yes setting in /etc/ssh/sshd_config, which is enabled by default. Do not disable it; fix the permissions instead.

3. Wrong User or Hostname #

Make sure you are connecting as the correct user. The key must be in that user’s authorized_keys file:

ssh deploy@remote_host

If you have a host alias in your SSH config file , verify it points to the correct hostname and user.

4. SSH Agent Not Running #

If your key is protected with a passphrase, ssh asks for the passphrase when you connect from a terminal. Scripts, cron jobs, and CI pipelines run without a terminal, so nothing can answer the prompt. The login fails even though the server accepts the key.

You can reproduce this with the BatchMode=yes option. It turns off all prompts:

ssh -v -o BatchMode=yes user@remote_host

debug1: Offering public key: /home/user/.ssh/id_ed25519 ED25519 SHA256:rIb41Chw7tL4ex2qmP85DZ9eFTStt9wXyI8jzIpi4nw
debug1: Server accepts key: /home/user/.ssh/id_ed25519 ED25519 SHA256:rIb41Chw7tL4ex2qmP85DZ9eFTStt9wXyI8jzIpi4nw
debug1: No more authentication methods to try.
user@remote_host: Permission denied (publickey).

The server accepted the key, but the client could not unlock it to finish the login. Loading the key into the SSH agent solves this.

Start the SSH agent and add your key:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

To list the keys currently loaded in the agent:

ssh-add -l

5. Wrong Key Being Used #

If you have multiple SSH keys, the client may be offering the wrong one. Specify the key explicitly:

ssh -i ~/.ssh/id_ed25519 user@remote_host

Or configure it in your ~/.ssh/config:

Host remote_host
    HostName 192.168.1.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519

6. Server Configuration Rejects the Login #

When the error lists publickey, key authentication is enabled on the server. The setting that blocks you is usually a different one. AllowUsers, AllowGroups, DenyUsers, and DenyGroups limit which accounts may log in over SSH. A user who is not allowed gets the same Permission denied (publickey) error, even with a valid key.

The main /etc/ssh/sshd_config file is not the only place to look. On Ubuntu, Debian, Fedora, and RHEL, it includes the files from /etc/ssh/sshd_config.d/ near the top, and the first value the server reads for a setting wins. A drop-in file can override a change you made in the main file.

Instead of reading each file, print the settings the server actually uses:

sudo sshd -T | grep -iE '^(pubkeyauthentication|authorizedkeysfile|allowusers|allowgroups|denyusers|denygroups) '

pubkeyauthentication yes
authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2
allowusers deploy

Key authentication is on, and the server reads keys from ~/.ssh/authorized_keys. The allowusers line shows that only deploy may log in over SSH, and every other account is rejected. Without an AllowUsers rule, the line does not appear.

After you edit the configuration, check it for syntax errors and restart SSH:

sudo sshd -t
sudo systemctl restart sshd

No output from sshd -t means the configuration is valid.

7. Key Type Not Accepted #

Some servers are configured to accept only certain key types. If your key type is not allowed, the server will reject it.

Old DSA keys are one example. OpenSSH 10.0 removed DSA support completely, so an id_dsa key no longer works with a current client or server. Generate a new Ed25519 key:

ssh-keygen -t ed25519

Then copy the new public key to the server with ssh-copy-id.

RSA keys still work. OpenSSH 8.8 disabled the old ssh-rsa signature algorithm, which uses SHA-1. Current clients sign RSA keys with SHA-2 instead (rsa-sha2-256 or rsa-sha2-512). The problem appears only when a new client connects to a very old server that supports ssh-rsa alone. In the verbose output, the client skips the RSA key instead of offering it.

To allow the old algorithm for that one server, add it to the host entry in ~/.ssh/config:

Host old_server
    HostName 192.168.1.20
    PubkeyAcceptedAlgorithms +ssh-rsa

This should be a last resort because ssh-rsa is deprecated on modern OpenSSH. A better solution is to upgrade the server and switch to an Ed25519 key.

8. SELinux Blocking Access #

On systems with SELinux enabled (Fedora, RHEL, and derivatives), SELinux may prevent the SSH server from reading the authorized_keys file.

Check for SELinux denials:

sudo ausearch -m avc -ts recent

Restore the correct SELinux context:

sudo restorecon -R ~/.ssh

9. Home Directory on Network Storage #

If the user’s home directory is on NFS or another network filesystem, the SSH server may not be able to read the authorized_keys file before the filesystem is mounted.

You can configure an alternative location for authorized keys in /etc/ssh/sshd_config:

AuthorizedKeysFile /etc/ssh/authorized_keys/%u

Then place the user’s keys in /etc/ssh/authorized_keys/username.

Server-Side Debugging #

If you have access to the server, check the SSH log for the exact reason SSH rejected the connection.

On Ubuntu and Debian, the SSH service is named ssh:

sudo journalctl -u ssh -f

On Fedora, RHEL, and derivatives, the service is named sshd:

sudo journalctl -u sshd -f

Systems that run rsyslog also write the same messages to /var/log/auth.log (Ubuntu and Debian) or /var/log/secure (RHEL and derivatives).

Keep the log open and connect again from the client. The log entries usually show whether the issue is permissions, a missing key, or a configuration mismatch on the server side:

Oct 16 19:18:56 ubuntu sshd-session[3336]: Authentication refused: bad ownership or modes for directory /home/user/.ssh
Oct 16 19:18:56 ubuntu sshd-session[3345]: Could not open user 'user' authorized keys '/home/user/.ssh/authorized_keys': Permission denied
Oct 16 19:22:46 ubuntu sshd-session[2596]: User user from 192.168.1.5 not allowed because not listed in AllowUsers

The first line means the permissions on ~/.ssh are too open. The second appears when root owns authorized_keys. The third comes from an AllowUsers rule that does not include the account.

For the most detailed output, run the SSH server in debug mode temporarily on a different port:

sudo /usr/sbin/sshd -d -p 2222

Then connect to it from the client:

ssh -p 2222 user@remote_host

The server will print every step of the authentication exchange to the terminal, which makes it easy to see exactly where the login fails.

Quick Reference #

For a printable quick reference, see the SSH cheatsheet .

FAQ #

Why does SSH care about file permissions?
SSH refuses to use keys with overly permissive file permissions because other users on the system could read your private key or modify your authorized_keys file. This is a security feature, not a bug.

I copied my key but it still does not work. What should I check?
Check the permissions on the remote ~/.ssh directory (700) and the authorized_keys file (600), and make sure the home directory is not writable by others. The files must be owned by the login user, not root. Also verify you are connecting as the correct user.

How do I check which keys the SSH client is trying?
Run ssh -v user@host and look for lines starting with debug1: Offering public key or debug1: Trying private key. This shows which keys are being offered to the server.

Does this error always mean a key problem?
Not always. The server returns the same error when AllowUsers, AllowGroups, or DenyUsers blocks the account, even if the key is valid. In that case, the server log shows a not allowed because message. If key authentication were disabled on the server, the error would not list publickey at all. With every method disabled, it reads Permission denied ().

Can I temporarily enable password login to fix the key?
Yes. If you have console access, set PasswordAuthentication yes in /etc/ssh/sshd_config, restart SSH, copy your key with ssh-copy-id, then disable password authentication again. On Ubuntu cloud images, /etc/ssh/sshd_config.d/60-cloudimg-settings.conf sets PasswordAuthentication no, and that file wins over the main one. Change the value there, then confirm it with sudo sshd -T | grep -i passwordauthentication.

I get this error on an AWS, GCP, or Azure instance. What should I check?
Cloud instances use a specific key pair set during provisioning. Make sure you are using that key: ssh -i ~/.ssh/my-cloud-key.pem user@host. The default username also varies by provider (e.g., ec2-user on Amazon Linux, ubuntu on Ubuntu instances, azureuser on Azure). Check your provider’s documentation for the correct username.

Conclusion #

Before disabling password authentication or closing your current session, open a second terminal and confirm that key-based login works end-to-end. Otherwise, a small mistake in sshd_config or in the authorized_keys file can lock you out of the server.

About the authors

Dejan Panovski

Dejan Panovski is the founder of Linuxize, an RHCSA-certified Linux system administrator and DevOps engineer based in Skopje, Macedonia. Author of 1000+ Linux tutorials with 20+ years of experience turning complex Linux tasks into clear, reliable guides.

View author page