Can't ssh even with public key added to authorized_keys
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:
ssh github
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:
.ssh/digitalocean-rsa
- PRIVATE key. Never share this.
.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:
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:
- Edit
/etc/ssh/sshd_config
PasswordAuthentication no
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:
sudo cp -r .ssh/ /etc/skel/
ls /etc/skel/.ssh
- 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:
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.
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 [email protected] -i .ssh/id_rsa
This might make debugging easier, and on the command line this should always work on the local computer.
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.