Solving the SSH Permission Denied (publickey) Error: A Step-by-Step Guide

The SSH Permission Denied (publickey) error message is something many of us have faced, and it's a real roadblock.

But errors are guardians of mastery.

Often, troubleshooting this error will give you insights about server management and network configurations that you might not have gained otherwise.

Understanding the underlying causes and following a systematic approach will help you regain access to your systems.

Table of Contents

Common Reasons for SSH Permission Denied (Publickey) Error

Preliminary Checks Before Troubleshooting

How to Diagnose SSH Permission Denied (Publickey) Error

Solutions to Fix SSH Permission Denied (publickey)


Common Reasons for SSH Permission Denied (Publickey) Error

Understanding why you're locked out is the first step in solving the problem. The reasons range from simple mistakes like a typo in the username or host address to more complex issues like incorrect file permissions or server configurations.

1. Incorrect Username or Host

One of the most straightforward reasons you might get the SSH Permission Denied (Publickey) error is that you've entered the wrong username or host address. 

Always double-check to make sure you're using the correct username and connecting to the correct server address. A small typo can make all the difference.

2. Missing Public Key on the Server

The SSH protocol relies on a pair of keys for authentication: a public key and a private key. 

The public key should be stored in a specific authorized keys file on the server you're trying to connect to. If it's not there, you'll be denied access. 

Make sure that your public key has been correctly uploaded to the server.

3. Incorrect Permissions for Keys and SSH Folders

Once you've verified that you're using the right username and that your public key is in place, the next thing to check is permissions.

SSH requires that only the user has read permissions to the private key file, usually ~/.ssh/id_rsa or a similar path. 

If the permissions are set too broadly, meaning other users can read or modify your private key, SSH will consider this a security risk and deny access. You can set the correct permissions using the chmod command on UNIX-based systems, ensuring that your private and public keys are only accessible to you.

4. SSH Service Configurations

Finally, there could be a problem with the server's SSH configurations. These settings are stored in a configuration file, usually at /etc/ssh/sshd_config on the server. 

This file contains various settings, such as which users can connect, what authentication methods are permitted, etc. 

If something in this file is incorrect, it can lead to the SSH Permission Denied (Publickey) error. 

You'll need to access this file and review the settings to ensure everything is in order. This requires root access to the server, so you may need to contact your administrator if you don't have the necessary permissions.

Preliminary Checks Before Troubleshooting

It's important to cover some basic checks before diving into the more complex reasons behind the SSH Permission Denied (Publickey) error.

Often, you can resolve it by confirming some simple yet crucial details. Here are preliminary checks you should make before going any further with troubleshooting:

1. Make Sure You Are Connecting to the Correct Server and Port

Ensure that you are connecting to the server's correct IP address or domain name. Also, SSH operates on a port, usually port 22, by default. Ensure you are connecting to the right port; if your server uses a different port for SSH, you'll need to specify it in your connection command.

To connect to a specific port, you can use the -p option in your SSH command like so:

ssh username@hostname -p port_number

2. Check That the SSH Service Is Running

Another essential check is ensuring the SSH service is running on the server. If not, you won't be able to connect, no matter what you try. If you have access to the server, you can check the status of the SSH service by running the following command:

On a Systemd-based system (like Ubuntu):

sudo systemctl status sshd

On an Init-based system:

sudo service ssh status

If the service is not running, you can usually start it with:

On a Systemd-based system:

sudo systemctl start sshd

On an Init-based system:

sudo service ssh start

3. Validate Username

Ensure you use the correct username for the server you're trying to connect to. A wrong username will lead to authentication failures. 

If you're unsure of the username and have access to the server, you can usually find a list of user accounts by looking in the /etc/passwd file or by running the getent passwd command.

These steps serve as a solid starting point for your troubleshooting process.

How to Diagnose SSH Permission Denied (Publickey) Error

When confronted with an SSH permission denied (ublickey) error, knowing how to diagnose the issue is half the battle.

1. Using SSH with -v (Verbose Option)

The -v option with the SSH command provides verbose output, displaying in detail the steps SSH takes during the connection process. This is extremely useful for identifying exactly where the process is failing. To use this option, open your terminal and enter:

ssh -v username@hostname

Carefully review the output. You'll see messages showing how SSH attempts to authenticate and any errors that occur along the way. This points you directly to the cause of the SSH permission denied error.

2. Locating and Checking the SSH Log Files

SSH usually logs its activities, which can offer valuable insights into what might be causing the problem. 

The logs are often stored in /var/log/auth.log on Ubuntu and other Debian-based systems or /var/log/secure on CentOS and other Red Hat-based systems.

To check these logs, use the cat or tail commands:

sudo cat /var/log/auth.log


sudo tail -f /var/log/auth.log

Look for entries that mention SSH and see if any error messages or warnings could provide a clue.

3. Verifying the Public Key on the Server

Another step is to ensure your public key is where it needs to be on the server. The key usually resides in a file under the ~/.ssh/ directory of the user you're trying to log in as, commonly named authorized_keys.

You can check the contents of this file with:

cat ~/.ssh/authorized_keys

Solutions to Fix SSH Permission Denied (publickey)

Finally, it's time to look at solutions.

1. Correcting Username and Host Information

Start by double-checking your username and the server's hostname or IP address. Typos or outdated information lead to this error. 

Verify the credentials and try connecting again.

If you are unsure of the username or hostname, consult your server administrator or hosting provider for accurate details.

2. Adding Your Public Key to the Server's authorized_keys File

One of the most common reasons for this error is that your public key is not found in the server's authorized_keys file.

You can manually add your public key to this file by using the ssh-copy-id utility or by appending it manually:

ssh-copy-id username@hostname

Or manually:

echo'your_public_key' >> ~/.ssh/authorized_keys

After adding your key, try connecting again to see if the issue is resolved.

3. Correcting File and Directory Permissions

Incorrect permissions also trigger this error. Ensure that your private key is readable only by you and that your .ssh directory has the right permissions. You can set these using the chmod command:

chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/
chmod 700 ~/.ssh

4. Tweaking SSH Configurations (sshd_config)

If you have root access to the server, you might need to dig into the SSH daemon configuration file (/etc/ssh/sshd_config).

Ensure that settings like PermitRootLogin and PasswordAuthentication are configured according to your needs. After making changes, restart the SSH service:

sudo systemctl restart sshd

5. Regenerating and Redeploying SSH Keys

If all else fails, you might have a corrupted key. In that case, regenerate your SSH keys and add the new public key to your server.

ssh-keygen -t rsa
ssh-copy-id username@hostname

6. Enable Password Authentication

As a last resort, if you're still encountering the issue and you have administrative access to the server, you can enable password authentication as a temporary measure. This will allow you to log in using your username and password, bypassing key-based authentication.

To enable password authentication, you'll need to modify the SSH daemon's configuration file, which is usually located at /etc/ssh/sshd_config. Open this file in a text editor with root privileges:

sudo nano /etc/ssh/sshd_config

Locate the line that reads PasswordAuthentication and change its value to yes:

PasswordAuthentication yes

If the line is commented out (starts with a #), remove the # to uncomment it. Save the changes and close the editor. Finally, restart the SSH service to apply the new settings:

sudo systemctl restart sshd

Now, you should be able to log in using your username and password.

However, enabling password authentication exposes your server to potential brute-force attacks. So, this should be a temporary measure until you can resolve the issues related to public key authentication.


Addressing the SSH permission denied (publickey) error is vital for maintaining secure, seamless access to your server.

Ignoring or bypassing this issue interrupts your workflow and poses a security risk.

We hope this guide is useful for diagnosing and resolving this common but solvable problem.

Items from an article
  • KVM NVMe VPS 16 GB
    • Country: Serbia
    • City: Belgrad
    • CPU 8 x Xeon Core
    • RAM 16 GB
    • HDD 200GB
    • BANDWIDTH 1 Gbps
    • IPv4 / IPv6
    € 88/month
    • Country: Romania
    • City: Craiova
    • CPU 4 x Xeon Core
    • RAM 8 GB
    • HDD 80GB
    • BANDWIDTH 1 Gbps
    • IPv4 / IPv6
    € 26/month
    • Country: Hungary
    • City: Budapest
    • CPU 2 x Xeon Core
    • RAM 4 GB
    • HDD 50GB
    • BANDWIDTH 1 Gbps
    • IPv4 / IPv6
    € 14/month
    • Country: Sweden
    • City: Stockholm
    • CPU 4 x Xeon Core
    • RAM 8 GB
    • HDD 80GB
    • BANDWIDTH 1 Gbps
    • IPv4 / IPv6
    € 26/month
Blog company: