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.

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.

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

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:

https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys–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/id_rsa.pub | ssh demo@198.51.100.0 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >>  ~/.ssh/authorized_keys"

Note: Replace 198.51.100.0 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!

Regards,
Alex

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.

Regards,
KDSys

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.