Error Permission denied (publickey) when I try to ssh

Posted March 16, 2017 1m views

Note from DigitalOcean Community team:
The user @intalix has provided a popular answer to this question here:

Recently I threw out my old linux laptop and set everything up again in my new laptop. The only trouble I have now is not being able to log in to my DO instance via ssh. This instance had one ssh key setup before and in the sshd config it had permitrootlogin set to no. So I created a new ssh key to be able to login from this new laptop.

$ ssh-keygen -t rsa -C "gitlab" -b 4096

Then added the public key this to the instance. Now I try to login

$ ssh user@server

I get asked password for this user. I am able to login using the password. This isn’t how I was logging in before. I used to type my ssh passphrase. So I thought this may be because this is a new key and I disabled password authentication in sshd config. After this, I get the error

$ ssh user@server
Permission denied (publickey)

I checked online and set the permission to .ssh folder to 700. Still I get the same error. I can access the online console of the instance, but don’t know what to do.

How do I resolve this?

edited by MattIPv4
  • I have the same problem. It worked for me in one server but when I tried the same process in other server it is saying “permission denied (publickey)”.
    Forunderstanding, I can log into x.x.x.216 but not into x.x.x.215 . actually both servers have everything i.e config same .

    can anyone say why its happening.

  • To me, works changing (Ubuntu 18.04):

    sudo nano /etc/ssh/sshd_config
    PermitRootLogin prohibit-password to PermitRootLogin yes 
    PasswordAuthentication no to PasswordAuthentication yes

    then, restart ssh service:

    sudo service ssh restart


  • This solution worked like a charm! thanks

  • Thank you @RildomarLucena that worked perfectly!

    My setup had PasswordAuthentication set to “no”, changed to “yes” and I was able to install ServerPilot.

  • This saved me! I’ve created dozens of droplets before but never had this issue until now. Thank you so much!!!

  • Show 2 more comments

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

29 answers

The issue is within your sshd_config file.

Here is the ULTIMATE solution to this issue:

  1. Log as root to your Ubuntu server

  2. Use vim or nano to edit the contents of /etc/ssh/sshd_config
    Eg. vi /etc/ssh/sshd_config or nano /etc/ssh/sshd_config

  3. Now go to the very bottom of the file (to the line with PasswordAuthentication) - Change the value next to PasswordAuthentication from no to yes.
    It should now look like this:

    # Change to no to disable tunnelled clear text passwords
    PasswordAuthentication yes
  4. Save the file and then run the following command to reload the SSH config:
    sudo service sshd reload

With this done, you can now set up your new SSH key for your LOCAL device.
To do this, you can run the following from your LOCAL device, not the server:

ssh-copy-id username@droplet.ip

(Make sure to replace username with your username on the droplet and droplet.ip with the full IP address of your droplet)

With this done, you should be good to go, connecting with SSH keys!

edited by MattIPv4


When you create a user using useradd, you’ll need to specify their home directory or use usermod to change it (as would be the case if the user already exists).

What I normally do is create the directories first:

mkdir -p /home/myuser/.ssh

Create the authorized_keys file:

touch /home/myuser/.ssh/authorized_keys

Then add the user:

useradd -d /home/myuser myuser

Set proper permissions:

chmod 700 /home/myuser/.ssh
chmod 644 /home/myuser/.ssh/authorized_keys

Set ownership:

chown -R myuser:myuser /home/myuser/*

Once that’s done, you should be able to login with myuser.

If you already have a user:

usermod -d /home/myuser myuser

and then continue with the above.

  • That was the ticket. I was following digital oceans tutorial for setting up a new user. The problem was folder ownership. All I had to do was chown -R myuser:myuser /home/myuser/* to the folder that was already created by adduser.

  • It should be chown -R myuser:myuser /home/myuser/, without the asterisk

I would like to discourage people from enabling PasswordAuthentication because it’s less secure than using an ssh key. Here is the answer you’re most likely looking for.

Short Answer:
As Root, run the following commands after creating the user:

  1. cp -r ~/.ssh /home/{new_user}/
  2. sudo chown -R {new_user}:{new_user} /home/{new_user}/.ssh

This is basically copying over the ssh key from the root user to the new user, which I would assume the new user is for you so you won’t have to login as root. If the new user is for someone else you can either create an ssh public key for them and give it to them or have them give you their existing ssh public key and place it in their /home/{new_user}/.ssh directory.

  • This should be the accepted answer.

  • From the docs

    Step 5 — Enabling External Access for Your Regular User

    rsync --archive --chown=sammy:sammy ~/.ssh /home/sammy

    Replace sammy with your username. This allows you to connect to your Ubuntu 18.04 droplet as user rather than root.

    You still need to tell PuTTY or ssh command line the location of your private key.

    This is the recommended secure way to do it. From what I’ve been able to gather, you do not want to enable password authentication unless you’re just messing around and learning. Don’t enable password authentication in any kind of production environment.

    by Justin Ellingwood
    When you first create a new Ubuntu 18.04 server, there are a few configuration steps that you should take early on as part of the basic setup. This will increase the security and usability of your server and will give you a solid foundation for subsequent...

Easy way:

  1. Connect to VNC (droplets>your droplet>Access>button “Launch Console”)
  2. Authenticate with your login and pass
  3. Open ssh config (vim /etc/ssh/sshd_config)
  4. Insert this string “PasswordAuthentication yes ”
  5. Save config
  6. Reboot ssh (service ssh restart)
  7. Try connect from your local machine
  8. Optionally add ssh-keys


I had the same issue and fixed it by updating the SSH config file on my local machine.


nano ~/.ssh/config

Then add these lines:

Host [your droplet ip]
  UseKeychain yes
  AddKeysToAgent yes
  IdentityFile ~/.ssh/[your private key file]

That’s it.

I do something similar.

curl >> .ssh/authorized_keys

For others in future, if nothing above works, another way to try:

  1. Have existing user, preferably root, create a file ‘authorized_keys’ on local machine, and copy the Public Key (.pub) of the new user into it in a text editor.
  2. If root, then modify and run this command:
    scp -i /home/MYUSER/.ssh/id_rsa /home/MYUSER/Documents/authorized_keys root@

  3. Of course, make sure that all the permissions and directories are properly created with proper permissions, etc., etc.,

One helpful tip with any SSH logins is to include -vT in the command, this will show you the entire connection/negotiating process and many times will point out issues. An example:

ssh -i ~/.ssh/id_rsa -vT root@123.321.123.321

chmod 600 ~/.ssh/xxidrsa

It should work

To me, works changing (Ubuntu 18.04):

sudo nano /etc/ssh/sshd_config
PermitRootLogin prohibit-password to PermitRootLogin yes 
PasswordAuthentication no to PasswordAuthentication yes

then, restart ssh service:

sudo service ssh restart


When trying to ssh into my droplet I got this error
root@XXX.XXX.XXX.XXX: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).”

My issue was that I use ssh to log into various servers (git, bitbucket and other servers).
I was able to resolve my problem by adding an entry to my ~/.ssh/config file.

vim ~/.ssh/config

  IdentityFile ~/.ssh/id_rsa

XXX.XXX.XXX.XXX = droplet IP
id_rsa = the ssh key file you use

Thank you, thank you thank you!
I read this answer like a week ago, let it digest and now I followed your instructions and it worked like a charm!

I have done all the above steps in my local machine and I still get the same error.

Permission denied (publickey)

Should this be done in my DO instance? If so, I remember seeing a authorized_keys file in the .ssh folder with some contents already presumably from the first time setup.

Should I append my publickey onto the authorized_keys file in the DO instance?

Hi @zaneakarl

I couldn’t get into it.

Then I tried opening the web console from digitalocean dashboard and pasting it there. The problem was that it is not possible to paste text onto the web console.

Luckily for me, I was able to copy the key from my another computer (mouse/keyboard connected via synergy) and paste it into a file tmp and the did:

cat tmp >> .ssh/authorized_keys

Immediately I was able to log into the droplet.

Now, thinking back I don’t really remember how I was able to paste the key into the tmp file in the first place. I checked the command history and am not able to find how I did it. Sorry.

If I find it, I will update it here.

From your local machine, run the ssh command: ssh root@your-droplet-ip

I’ve wasted time on this issue on three seperate occasions. I am about 20 minutes away from leaving DigitalOcean for good.

1) If web UI console is going to be the only reliable way to boot into a box after password reset, add paste functionality.
2) I can’t put my finger on it, but I believe the web UI pw reset breaks more things then it fixes, ssh with a key is a struggle to get working

Ahh I’m switching now.

  • I’ve had DO for years and never had a problem like this. Come to think of it, I’ve been using Linux since the late 90s… and I’ve never had such a hard time. I half want to just delete my droplet and start from scratch. What a crap-show. (Yes, I’m experiencing the same problem)

  • If you chose public key authentication you must learn to use it. It is not DigitalOcean’s fault, if the cause was the same as in my case. The key (where x is the full path you gave during ssh-keygen) must be added on droplet creation if you want to use public key authentication. Then you must add the private key file to your local system with ssh-add x (where x is the full path you gave the file during ssh-keygen). Then you can do ssh root@$IP where $IP is the droplet’s IP address. You won’t need a password if it worked.

Hi, just solve this issue with the same method above.
1) open with web UI console
2) wget https://xxxxxxx
3) cat > .ssh/authorizedkeys

There seems to be some problem with the setup of Droplet.
The .ssh/authorizedkeys wasn’t correct originally.
The “vim -d id .ssh/authorized_keys” said they are different.
then do the third command.
and everything works.

hope this helps.

Try running ssh-add on your client machine.

When I write chown -R myuser:myuser /home/myuser/* to command line
I get a warning below.
chown: cannot access ’/home/myuser/*’: No such file or directory

Thank you

FWIW. In my case the error “Permission denied (publickey).” was caused by non-existent shell in the /etc/passwd for the particular user (/usr/local/bin/bash in FreeBSD and bash was not installed). When I changed the shell to /bin/sh (chsh -s /bin/sh user) I was able to ssh to this account. HTH.

Easiest solution is provided by @intalix .
I tried to copy paste through the web console but the text encoding was totally messed up.
Also on a user point of view, I thought that adding my ssh key into my account security settings was enough to add it to the authorized list. But it doesnt.

I’ve been using various distros of Linux since the mid-90’s. (Just saying, I’m not a complete rookie with config and security, etc..) But I have spent HOURS (5 or 6) on this “Permission denied (public key)” issue with DigitalOcean and have not found the magic solution. I am giving up, deleting the two droplets I had, and moving on to a different host (I’ll see about Rackspace). I’ve had web sites (with databases, etc.) up on AWS for years, and I was just looking around at possible alternatives. DO isn’t one of them, I’m very sorry to say.

These answers merely omit using a key, which is the point in the first place.
Can someone actually come up with this answer??
Using Ubuntu 18.04
Key permissions are set to 400 ( owner read-only)

I got this from the tutorial of Initial Server Setup with Ubuntu 18.04 (

If the Root Account Uses SSH Key Authentication
If you logged in to your root account using SSH keys, then password authentication is disabled for SSH. You will need to add a copy of your local public key to the new user’s ~/.ssh/authorized_keys file to log in successfully.

Since your public key is already in the root account’s ~/.ssh/authorized_keys file on the server, we can copy that file and directory structure to our new user account in our existing session.

The simplest way to copy the files with the correct ownership and permissions is with the rsync command. This will copy the root user’s .ssh directory, preserve the permissions, and modify the file owners, all in a single command. Make sure to change the highlighted portions of the command below to match your regular user’s name:

rsync --archive --chown=sammy:sammy ~/.ssh /home/sammy

replace ‘sammy’ with your username

I would like to mentioned that DigitalOcean have a really useful tutorial on how to setup your ssh keys on a droplet. Here is the link:–2

In short the process is not that difficult. I would like to mention few scenarios and how to solve them.

  1. You can’t access your droplet via ssh-key and you get the Error Permission denied (publickey) error message.

What you can do is to access the server using the DigitalOcean console and from there either add your key to the authorizedkeys file or simply enable the password authentication by adjusting the config file - “`/etc/ssh/sshdconfig”`

PasswordAuthentication Yes

then restart sshd:

systemctl restart sshd

Once this is done you can now access your droplet using your password and you can copy your key from your local machine using this command:

cat ~/.ssh/ | ssh demo@ "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >>  ~/.ssh/authorized_keys"

Note: Replace with your actual droplet’s IP address

You can now access your droplet using a ssh-key and what you should do is to disable the password authentication by simply undo the last change you made in the sshd_config file.

  1. You can’t access the server via ssh-key but the key is already added to the server. In case this happens there are several things you need to check:

Your private key file (on the local machine) must be readable and writable only by you: Permissions need to be 600.

so make sure that your SSH key is set with proper file permissions:

chmod 600 /users/name/name-of-private-key

Note: Change the /users/name/name-of-private-key with the actual path to your private key.

Your ~/.ssh/authorized_keys file (on the remote machine) must be readable (at least 400), but you’ll need it to be also writable (600) if you will add any more keys to it. So you can make sure it’s both readable and writable:

chmod 600 /root/.ssh/authorized_keys

Then try to SSH again and if you still get the same error try running SSH with verbose mode by adding the -vvv tag:

ssh -vvv -i /users/name/name-of-private-key userid@ip

Hope this helps!


Hi all,

Let’s first being with the usual stuff:

  • Your home directory ~, your ~/.ssh directory and the ~/.ssh/authorized_keys file on the remote machine must be writable only by you: rwx------ andrwxr-xr-x are fine, but rwxrwx---is no good, even if you are the only user in your group (if you prefer numeric modes: 700 or 755, not 775).
  • If~/.ssh or authorized_keys is a symbolic link, the canonical path (with symbolic links expanded) is checked.
  • Your ~/.ssh/authorized_keys file (on the remote machine) must be readable (at least 400), but you’ll need it to be also writable (600) if you will add any more keys to it.
  • Your private key file (on the local machine) must be readable and writable only by you: rw——-, i.e. 600.

Now that we’ve passed the standard stuff, let’s get going on the more interesting stuff.

When you run

/usr/sbin/sshd -d -p 2222

On your droplet, you can then connect without a password, what does the debug information says on your droplet, It should state something like

Authentication allowed

In this case, what you can do is temporarily stop the SSH daemon and replace it with one in debug mode. Don’t worry, stopping the SSH daemon won’t kill any existing connections. This means it’s possible to run this without being connected to the droplet’s Console but it’s somewhat risky. If the connection does get broken for any kind of reason, you’ll need to connect using your droplet’s console. Anyway, you can run the following

service ssh stop
/usr/sbin/sshd -d
#...debug output...
service ssh start

If it again runs with the debug mode being on, then for sure it’s the SELinux causing the issues, it’s most probably set to Enforcing. The .ssh dir will probably be mislabeled. Look at /var/log/audit/audit.log. Check with ls -laZ and then Run restorecon -r -v /path/to/users/.ssh.


I agree with not enabling PasswordAuthentication or PermitRootLogin. One problem with key authentication leading to the Permission denied (publickey) error is that the user’s home folder, not only the .ssh folder must not have group write permissions if the group is different from the username.

You just need to grant the local user ownership of the xxx-key.pem file.. Where “my-key.pem” is the name of your file, and “linuxuser” is your local:

sudo chown linuxuser my-key.pem

…and thats it!
You will have to do this whenever you move the key to a new system

Submit an Answer