14

I have a Digital Ocean droplet I'm trying to give myself ssh access to. I'm not sure what was done to it previously. I've tried added my public key through the Digital Ocean UI. That didn't work, I kept getting permission denied (publickey).

I accessed the server through the Digital ocean console and manually added my public key to /root/.ssh/authorized_keys. I then tried to ssh using ssh root@x.x.x.x. That didn't work (permission denied).

So I tried adding a new user, created the /home/me/.ssh directory with permissions 700 on the .ssh directory itself, and 600 on the authorized_keys file. Then I tried ssh me@x.x.x.x. That didn't work either.

Restarting the ssh daemon doesn't change anything either.

What am I missing?

Edit:

Here is verbose ssh output.

https://gist.github.com/jaesung2061/a37cfd68308414cede8abf7f0137daa9

Edit 2:

LogLevel DEBUG3 output:

enter image description here

  • Post the verbose log from the connection, your content of sshd_config and possible errors related to ssh in the server log. – Jakuje Jan 14 '17 at 14:24
  • @Jakuje I've added the output... I didn't notice your comment before. – Jeff Jan 21 '17 at 18:11
  • The key is rejected. Check the server log for possible issues (possibly with LogLevel DEBUG3 in sshd_config). I suspect these are permission issues, but there might be several reasons for this. – Jakuje Jan 21 '17 at 20:48
  • It says [date omitted] www sssh[15029]: Connection closed by x.x.x.x port 55519 [preauth] – Jeff Jan 21 '17 at 21:04
  • What are the permissions of the authorized_keys file? ls -ld ~ ~/.ssh ~/.ssh/authorized_keys? For the verbose log from server modify the file mentioned above, restart ssh service, connect again and post the log (should be also in auth.log. – Jakuje Jan 21 '17 at 21:07
19
+100

Client Configuration

Set up ~/.ssh/config

Setting up host entries for ssh is really easy and will save you a lot of trouble. Here is an example:

Host digitaloceanbox
Hostname 111.111.111.111
User root
PubKeyAuthentication yes
IdentityFile /home/user/.ssh/digitalocean-rsa
ForwardX11 yes


Host github github.com
Hostname github.com
User git
PubKeyAuthentication yes
IdentityFile /home/user/.ssh/github-rsa
ForwardX11 no

In this example, we setup digitaloceanbox and github and github.com so that we can do the following commands:

  1. ssh github
  2. ssh digitaloceanbox

If we want to login as a different user than the one specified in the config file, we just put user@ at the begining:

  • ssh user@digitaloceanbox

Generating ssh keys

ssh-keygen -t rsa -b 4096 -C user@homemachine
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):  /home/user/.ssh/digitalocean-rsa
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/user/.ssh/digitalocean-rsa
Your public key has been saved in /home/user/.ssh/digitalocean-rsa.pub.
The key fingerprint is:
SHA256:p9PYE/tveF2n//bLbp3ogYDtMtYEC5ziQiPxeob6fbo user@homemachine

Note that I've specified the full path of the private key I want to generate when prompted by ssh-keygen. I've also defined the comment (-C) which allows me to easily identify keys on remote machines.

This will create two files:

  1. .ssh/digitalocean-rsa
    • PRIVATE key. Never share this.
  2. .ssh/digitalocean-rsa.pub
    • Public key. This is what you store on the server to authenticate.

When you provide your ssh key, be sure it's the .pub version!! When you add to your ~/.ssh/config, be sure to add the correct private key that matches the public key you added to the system.


Server Configuration

Most installations will come with Public Key Authentication enabled. If you start doing things all willy nilly, you might run into a few problems, however. At where the OP is in their problem, I recommend that the OP deletes the /root/.ssh/ directory to start over.

It is not recommended that you use ssh to access the root user on the remote system. It is recommended that you ssh into another user, and then escalate to root using your password (sudo su -).

Add keys to host using ssh-copy-id

Regardless of whether you decide to create another user and use ssh as that user, or the root user, the following is the recommended way of placing ssh keys on a server:

  1. ssh-copy-id -i /home/user/.ssh/digitalocean-rsa.pub user@digitaloceanbox

This allows sshd to create the directory and files needed with the permissions needed. This means there is zero chance for you to mess up permissions or needing to remember the details. Just use the tool to upload the keys.

Disable Password Authentication

That being said, once you have key'd yourself and verified that you are able to connect using the keys, it is recommended that you disable Password Authentication in sshd and restart the service:

  1. Edit /etc/ssh/sshd_config
  2. PasswordAuthentication no
  3. sudo systemctl restart sshd

What about new users?

If you disable Password Authentication, how can you key new users? One way is to add template files to the /etc/skel directory. Once you've key'd one user, do the following:

  1. sudo cp -r .ssh/ /etc/skel/
  2. ls /etc/skel/.ssh
  3. Edit any files found in /etc/skel/.ssh/ so that they are blank, unless you want to automatically key yourself for every newly created user.

When you create new users with sudo useradd -m newuser, that user will have the .ssh/authorized_keys, which you can edit and will have the proper permissions.

Debugging

You can watch the sshd log file to see why connections fail or get refused:

  1. sudo tail -f /var/log/auth.log

While you're running this command, use another terminal to attempt a login. Many times the messages provided are good enough to help pinpoint the problem, or find a solution online.

  • 1
    The debugging step worked for me. The root directory had the wrong permissions (needed to be 700) – naisanza Sep 22 '17 at 7:15
12

Ssh is quite picky about ownership, file and directory permissions with ssh keys.

~/.ssh/ should be owned by the owner and have 700 permissions. ~/.ssh/authorized_keys should be owned by the owner and have 600 permissions.

So, for root :

sudo chown root:root -R /root/.ssh/
sudo chmod 700 /root/.ssh/
sudo chmod 600 /root/.ssh/authorized_keys

For user me :

sudo chown me:me -R /home/me/
sudo chmod 700 /home/me/.ssh/
sudo chmod 600 /home/me/.ssh/authorized_keys

And then try again.

Of course you should also check in /etc/ssh/sshd_config whether root is allowed to log in at all, or just with ssh keys.

If you have :

PasswordAuthentication no

then you can set :

PermitRootLogin yes

And then restart sshd :

/etc/init.d/sshd restart

and try again.

Note that with ssh, the sshd daemon can be restarted even when using an ssh session for this.Openssh is designed to deal with that.

Looking at your uploaded log file snippets, it seems that you are using MacOSX ? Could you create a new ssh key there ?

Furthermore, I found out in the past that when I have more than one private ssh key on my local computer for my user, that this sometimes makes it impossible to log in remotely with ssh. It helped a great lot to make entries on the local computer in the file ~/.ssh/config, to solve this. For example :

Host my-vps
  HostName my-vps-ip-address-here
  IdentityFile ~/.ssh/id_rsa-my-private-key-location
  User my-username-here

After that try on the command line on your local computer :

ssh -v my-vps

When using ssh keys, as well as no ssh keys for some other logins, you can, besides entries with ssh keys, also define a ssh login without ssh key usage in the ~/ssh/config file, for example :

Host pi
  Hostname 192.168.1.111
  Port 22
  User pi
  PasswordAuthentication yes
  PreferredAuthentications password

This works fine for me. It is also possible to define which key to use on the command line :

ssh -v root@10.111.111.254 -i .ssh/id_rsa

This might make debugging easier, and on the command line this should always work on the local computer.

  • In addition to this solution, I had to change the permissions for my home folder too, to get the SSH working: sudo chmod 700 /home/me/ – Rg90 Oct 21 '18 at 13:55
  • You're a lifesaver, @albert-j! The IdentityFile line got me out of an hour-long rut. – zev Jan 17 at 14:40
4

Double check the ssh daemon configuration (should be in /etc/ssh/sshd_config) and check for:

PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys

Also check the configuration file to see if AllowUsers or AllowGroups has been set, as they act as white lists for user and groups respectively.

Also, I noticed you're trying to add a key to the root user. By default root login should be disabled, but you can also change this via the PermitRootLogin field.

  • None of these are working :/ I still get Permission denied (publickey) – Jeff Jan 15 '17 at 7:09
3

According to the logs you have linked, I think you have problems in the client side not finding the private key file.

  • First check the file ~/.ssh/id_rsa exists on your local machine, and is the correct one _(if you have more).

  • Check .ssh folder permissions (should be drwx------, if not run sudo chmod 700 ~/.ssh) and its contents (should be -rw-------, if not run sudo chmod 600 ~/.ssh/*). Apply the same permissions for the remote machine too.

Additionally, you can try to force using your desired private key, giving it directly to ssh with the -i parameter.

  • You can run something like the followings:

    ssh -i /path/to/your/private-key root@X.X.X.X

    or

    ssh -i ~/.ssh/id_rsa myRemoteUser@X.X.X.X

You can get more info on ssh manpage (run man ssh on your terminal).

Also keep in mind if you want to login as root user, your root account has to be enabled prior to login, creating a passwd for it with sudo passwd root or your server administration tool (Ubutntu has root account disabled by default). You can get more info at Ubuntu Wiki.

Hope it helps.

3

I ended up reinstalling openssh-server which fixed the issue. The solutions given are all great, but they didn't work for me. I have no idea what was causing the issue but I think the previous developer may have messed with the configuration and messed things up pretty bad.

I doubt there will be anyone with such a specific issue as mine. However, if you have a Digital Ocean droplet, you cannot get SSH access, and none of the given solutions work, reinstall the SSH server by running these commands through the Digital Ocean console. Beware this is a destructive process and will erase old configuration files in /etc/ssh/ (not your .ssh directory).

apt-get purge openssh-server
apt-get autoremove
apt-get autoclean
apt-get install openssh-server

Assuming your ssh client/keys are in order, you should be able to SSH into your server.

1

This issue popped up for me using the Debian image on Digital Ocean. Somehow during the brief set up process, probably when I set the root password, the owner for /root was changed to the user debian. I saw the following in /var/log/auth.log:

Jul 26 20:58:17 docker sshd[12576]: Authentication refused: bad ownership or modes for directory /root

Simply executing chown root:root -R /root solved the issue.

HTH

0

Just had a very similar problem. This worked for me - Add this line to /etc/ssh/sshd_config

AuthorizedKeysFile %h/.ssh/authorized_keys 

Then restart ssh in the usual way.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.