When I access my server via SSH, it returns permission denied (publickey) error in my DigitalOcean Droplet. What’s wrong with my server?
That was a recent support ticket received at our DigitalOcean Managed Services department where we resolve support queries for web hosts.
Droplet owners often use key based authentication to improve security on their servers.
But, what happens if these SSH keys are not configured properly? Result is, server denies access and kicks you out with errors.
One such error is “Permission denied (publickey)“.
Today, we’ll discuss the top 4 reasons of this error and how our Cloud Experts fix them.
Permission denied (publickey) in DigitalOcean – What’s this?
Before we go to the reasons of this error, let’s get an idea of this error first.
A key based authentication needs a private key and a public key pair.
The public key is placed on the Droplet while the private key is placed on the user’s computer.
And, users submit this private key to authenticate and connect via SSH.
The error “Permission denied (publickey)” clearly shows that there is a problem with the SSH keys used for authentication.
Since publickey is shown in the error message, it doesn’t mean that the public key is the problem.
Actually, this error shows that the public key of the Droplet rejects the private key provided during authentication.
So, our Support Engineers recreate the problem by connecting to the server via SSH in debug mode.
ssh -vvv 195.xxx.12x.15x
It will therefore give a detailed trace of the connection that will help us to analyze the problem.
In addition to that, we check the SSH logs(/var/log/auth.log or /var/log secure) to see why this error occurred.
Permission denied (publickey) in DigitalOcean – Causes and Fixes
Now, let’s see the main reasons for this error and how our Support Experts fix them.
1) Wrong private key
Most often, this error comes up when Droplet owners use the wrong private key to connect to the server.
Similarly, sometimes Droplet owners change the private key name, but use the wrong key name when connecting via SSH.
How we fix?
In this case, the easiest way to confirm that the private key causes problems, is to create a new key pair, and connect with the new set of keys.
If that works, we’ll update the customers to check and correct their private key file and location.
But, we always recommend that customers create a new key pair to connect to the server.
2) Incorrect SSH key permissions
SSH enforces strict permission on key files by default.
In other words, if any of the files in the .ssh folder can be written by anyone other than the user, then SSH refuses to authenticate.
Because, hackers can easily modify/replace key files, if the parent directories can be written by others.
Similarly, there are cases in which users don’t have sufficient permission or ownership to read the private and public key.
In both cases, the DigitalOcean server shows Permission denied (publickey).
How we fix?
The ideal permission of .ssh folder should be 700 and the files in .ssh folder should be 600.
So, our Hosting Engineers first check the permission and ownership of the .ssh folder and the files in this folder.
And, if any permission or ownership related errors are noted, we correct them immediately.
Most importantly, we ensure that the permission of the .ssh/authorized_keys file is 600, because it’s the file where public key is stored.
3) Missing public key in remote host
The public key generated at the localhost should be added to the remote host for any new users created on the server.
This key pair is used by the remote host to identify the user’s machine while connecting via SSH.
Ideally, the public key should be stored at /home/user/.ssh/authorized_keys in DigitalOcean Droplets.
However, we’ve seen cases where Droplet owners fail to add this key to the remote host.
As a result, SSH kicks them out with the error permission denied (publickey).
How we fix?
Our Hosting Engineers first verify the authorized_keys file location in SSH configuration file /etc/ssh/sshd_config.
To add the user’s public key to this file, we open the .ssh/authorized_keys file and copy the public key.
Most importantly, we restart the SSH service to reflect the changes.
In most cases, we recommend that users use the ssh-copy-id utility(if it is supported) to copy the public key to the remote host, because it automatically add/create the required files and directories and assign proper permissions.
So, there is no chance for users to mess up the permissions.
Otherwise, we need to manually add the SSH key to the remote host.
4) Incorrect username/hostname
Similarly, when users use incorrect SSH username, incorrect IP or host, they will come up with the error permission denied (publickey).
This is because, there will not be a matching public key for the private key that users submit.
How we fix?
Our Support Engineers try to create a new key pair in such cases. If that doesn’t work, we check the SSH connection settings.
We ensure that there is no typo in hostname and it resolves to the customer’s Droplet IP using the dig command.
dig server.hostname.com
Additionally, we ensure that the IP address is up using the ping command.
ping IP_ADDRESS
Conclusion
In short, DigitalOcean SSH error ‘permission denied (publickey)’ can occur due to wrong SSH key permissions, wrong SSH username, and more. Today, we’ve discussed the top 4 reasons for this error and how our Cloud Experts fix them.
There is a peculiar error on my DigitalOcean droplet.
Whenever my droplet reboots, both idrsa key (putty format for FTP) and id_rsa.pub key (open ssh format for bash terminal) get deleted from the server.
Then I load pvt keys in my local pc or directly open public key files, copy their text and insert that text in remote hosts ‘autorized_keys’ file. And then my sFTP and bash login both start working.
May not be related: nginx also needs to be enabled/started at every reboot.