For this tutorial I have the following setup: my desktop client is PostX Gnu/Linux(Debian based) and my server machine is Lubuntu´s latest image (as it was during October 2017).

SSH is a secure shell network protocol, which let’s you to form a connection from one computer to another securely over the network. SSH can be used to access remote devices, which are online somewhere but you can also use SSH to access devices on your LAN(devices like Raspberry PI).

We will be using OpenSSH. It comes in two parts: it has the client and the server. You need to install the server part to the machine that you want to access and the client part to the computer(s) accessing the server.

On Debian based systems this is usually as easy as:

sudo apt-get install openssh-client #for the client.

sudo apt-get install openssh-server #for the server.

On most larger sized desktop Linuxes OpenSSH is installed by default.

In my case, I installed both packages manually – as outlined above.

Basic connecting

Connecting to an SSH server enabled computer with password authentication is as easy as:

ssh user@123.123.1.1 #Replace user with the right remote(server´s)  username and 123.123.1.1 with an actual IP address.

How to find out device IP address?

When connecting to a server you need to know its IP. When we are connecting to a device on Lan(behind a router), finding the IP is easy with nmap. Do: sudo apt-get install nmap and then start the scan with:

nmap -sn 123.123.1.0/24

Replace the IP with a real one but make sure that the ending, 0/24, remains the same. 0/24 makes sure that we scan the entire range. In same cases your subnet mask bit range may be different(like 16: 255.255.0.0) but 24 is the most common and it points to 255.255.255.0 subnet mask.

Creating keys for SSH

The password authentication method above has one downside: it is deemed insecure. A lot nicer way is to create some GPG keys and pass them between hosts. Furthermore, I do recommend that you protect your public key with a password(this option is asked during the key creation). If your key gets lost you need to generate a new one. With a local network this is not so bad. With a larger-scale network the situation might however become troublesome – since if the keys get passed to a hostile entity it might lead to some security and data breaches. GPG keys are like credentials, which give access to certain things. So, my recommendation is that you should take a good care of them.

To create a GPG key for SSH do:

ssh-keygen -b 4096 -t rsa #RSA2 formatted key gets created with 4096 bits. 2048 is the default; 4096 is more secure but a bit slower and might also have some issues with certain server setups.

ssh-keygen produces output like below:

____________________

Generating public/private RSA key pair.

Enter file in which to save the key (/home/user/.ssh/id_rsa): #Enter filename. This tutorial uses defaults.

Enter passphrase (empty for no passphrase): #password here.

Your identification has been saved in .ssh/id_rsa.

Your public key has been saved in id_rsa.pub.

The key fingerprint is:

SHA256:random stuff user@device

The key’s randomart image is:

________________________

The above creates two files files:

 id_rsa and id_rsa.pub inside .ssh folder.

Id_rsa is the private key and id_rsa.pub is the public key. You cannot decrypt the public key without the private key.Also, as the name implies: public key will be the one that gets transferred to the server while we keep the private key safe in our desktop machine. Note. Double-check that both keys end up to the folder path: /home/user/.ssh/ ← in the desktop machine.

Next we will transfer the public key to the server machine.

If we would have a custom named key we could do:

ssh-copy-id -i /home/user/.ssh/keyname.pub  user@123.123.1.1

However, I recommend sticking with the default names id_rsa and id_rsa.pub for now. This avoids some configuration headaches. Use the command structure outlined below.

ssh-copy-id user@123.123.1.1

The command above will append .pub key´s content to the server´s .ssh folder’s authorized_keys file.

Now, login to the server accept the added .pub key. The previous means that you enter passwords and follow instructions printed to the screen.

ssh user@123.123.1.1#Login to the server and say yes to (desired) changes.

Next, list the files in the .ssh directory. You should find the authorized_keys file.

ls .ssh

Check the content of authorized_keys with:

cat .ssh/authorized_keys

Make sure that no mention of a private key is found and that this is actually the public key that got appended to the authorized_keys file.

After the above steps, make sure to secure your SSH server properly.

In the server:

cd /etc/ssh #Go to SSH configuration directory.

sudo cp -R sshd_config sshd_config.orig #Let’s copy the original settings file just in case.

sudo nano sshd_config #Open settings file as a sudo and with nano(or something else, like vim) and make some changes:

Port 12345 #Change port number to something else than 22 to avoid attacks.

#Authentication

LoginGraceTime 1m #Sever the SSH connection if login does not happen in one minute

PermitRootLogin no #Disable login for the user: root.

MaxAuthTries 3 #Set maximum authentication tries to 3 instead of 6.

PubkeyAuthentication yes #Allow authentication using .pub keys.

DenyGroups root #Deny root group.

# To disable tunneled clear text passwords, change to no here!

PasswordAuthentication no #Disable password authentication.

PermitEmptyPasswords no #Not strictly needed since we disable passwords anyway. But it is #good to be explicit.

Also consider adding:

ClientAliveInterval 600 #Disconnect session after 10 minutes of inactivity.

AllowUsers my_user my_other_user #Allow only these two users to access. If you wish to allow all except some use: DenyUsers or even DenyGroups.

Note that AllowUsers means the users residing on the server´s side. For example, on the server there is a user called tester. You put tester into AllowUsers. Now, you can login via SSH as tester.

SSH configuration file has many entries, so read them carefully and customize according to your needs. Once you are done, save the file.

Linux firewall

Before a server restart make sure that you create a new custom rule in your server´s firewall – so it can receive SSH from our custom port. We do not want to get a connection refused notification upon login.

You can either allow all traffic from LAN to a server with: sudo ufw allow from 123.123.1.0/24

OR

You can allow traffic from a specific host to a server with: sudo ufw allow from 123.123.1.80

Replace the IPs with actual IPs. Personally, I think that,especially with firewalls, being specific is always better than being generic.

Remember that by default many Linux systems come with firewall disabled and due to that they also come with all ports closed by default. We need to make sure our firewall is running – so that our rules will apply.

sudo ufw enable #Enable the firewall.

sudo ufw status #See status and verify that the traffic from our specified source is allowed.

If ufw is not installed at all by default: sudo apt-get install ufw will fix that.

Now, restart the server’s SSH or the entire server machine. You can use sudo service sshd restart . You can also reboot the entire machine so that changes can take effect:sudo reboot

If you get any errors with sudo service sshd restart it means that you likely made a typo in the sshd_config file. When possible use service restart method.

After SSH server is restarted: type exit to quit the SSH connection. Now, retry the connection. This time we can only use our key to login.

Now, you should be able to login to SSH server with your public key’s password and the public key. Say goodbye to the insecure legacy password authentication and enjoy a more secured way of login in with a key.