SSH: OpenSSH 8.2p1
Enabling SSH Key Login is a great way of protecting your SSH access to the cloud server. In the event that you still prefer password login (For convenience if you access the SSH server from multiple machine and does not want to port your SSH private key around. It is still recommended to disable using root for ssh login. So let’s start by creating a new user.
sudo adduser <username>
If you disable root login or have disable root password. It is important to add at least 1 user to sudoer group, so that you can ssh in with a privileged user to carry out your administrative activities.
sudo usermod -aG sudo <username>
Sample logs in /var/log/auth.log when you add a new user.
sudo cat /var/log/auth.log
Now that we have a created a user with sudo rights we can modify the /etc/ssh/sshd_config file to disable root login. You can use any text editor in this tutorial I am using nano as my text editor.
Remember to restart ssh service.
sudo systemctl restart sshd
Once that is done you can login using the new user. You can see from the /var/log/auth.log that the new user has logon and root user is unable to login now. The error message shows Failed password even thou the right password is provided that is normal in Debian. You might see different messages on other linux platform.
Now we are ready to start configuring ssh for ssh login using ssh keys. For beginners it can be quite confusing if you are not too familiar with the public and private keys concept. I will try and make is as simple as possible in the explanation and configuration.
I have color coded the steps to highlight if it is a client side or server side step.
Client side steps.
Server side steps.
First thing to take note is after you generate the key
1. The private key should be stored in the Client Machine
2. The Public key is the one that will be stored in the server.
In this tutorial I am generating the keys on the client machine itself you can use any machine to generate the ssh key. But do take note if you are going to move the private keys around it is good to give it a passphrase.
Next in the user directory that you are allowing ssh. Create a .ssh folder and a authorized_keys file if it does not exist. In Debian the default install does not create that. Below are the steps to create the file.
mkdir /home/<user directory>/.ssh
touch /home/<user directory>/.ssh/authorized_keys
Then copy the PUBLIC KEY that you have generated into the authorized_keys file. You can just copy and paste with any of the text editor. You can also use ssh-copy-id to do it before you turn off the password login.
ssh-copy-id -i <private key that you have created> <username>@<target server ip>
Then modify the /etc/ssh/sshd_config file to enable PubKeyAuthentiation yes.
And change PasswordAuthentication to no.
Save the configuration and restart the sshd service.
On the Client Machine now you can login using the private key, specific the location of the private key (identity) if you are not using the default key store.
If you have set a passphrase for the private key you will be prompted to enter the passphrase. Do take note this is the passphrase you have enter during the key creation and not the user password.
Once you do that you will be login to the target ssh server.
Under the /var/log/auth.log you will see that you have logged in using the publickey for Alice.
It can be quite confusing as we have just used the private key as the identity. Why does it mentioned public key when we actually specify the private key for the SSH connection. You can read more in depth about key exchange in my future tutorial but for simplicity if you remember enter the public key in authorized keys earlier. The key exchange that happen has verified through mathematical formula that the private key you supplied and the public key you specified in the authorized key is a key pair and therefore the public key is accepted as part of the login.