Error Permission denied (publickey) when I try to ssh

March 16, 2017 267.3k views
DigitalOcean Debian

Note from DigitalOcean team:

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?

  • 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

19 Answers

the issue is within : sshd_config file

here is the ULTIMATE solution:

  1. Log as as a root to you Ubuntu server
  2. vi /etc/ssh/sshd_config

Now go to very bottom:
And change the value from "no" to "yes".

It should look like this:

Change to no to disable tunnelled clear text passwords

PasswordAuthentication yes

  1. service sshd reload

to take effect.

Now you can simply a key using following command from your LOCAL machine (aka laptop etc)

So Open new terminal window and do NOT log into server, simply put this command:

ssh-copy-id john@serverIPAddress

(Replace john with your username).

you should be go to go


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.

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 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.

  • Shoot, well thanks for trying anyway.

  • Your solution worked for me. To add the "tmp" file. I uploaded my with the wget command. i.e.:


    then I used your command:

    cat  >> .ssh/authorized_keys


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)

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.

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

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.

chmod 600 ~/.ssh/xxidrsa

It should work

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'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.

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


Have another answer? Share your knowledge.