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!

@animesh

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.

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

Profit!

I do something similar.

curl http://www.domain.com/file_path/id_rsa.pub >> .ssh/authorized_keys

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

First:

nano ~/.ssh/config

Then add these lines:

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

That’s it.

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

Thanks!

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

Host XXX.XXX.XXX.XXX
  IdentityFile ~/.ssh/id_rsa

Where,
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!

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

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

There seems to be some problem with the setup of Droplet.
The .ssh/authorizedkeys wasn’t correct originally.
The “vim -d idrsa.pub .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@123.123.123.123:/home/NEWUSER/.ssh/authorized_keys

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.

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.

Worked, thanks!

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 (https://www.digitalocean.com/community/tutorials/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:

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

replace ‘sammy’ with your username