Now that we have installed the OpenSSH server on the Linux box and thereafter successfully connected using Putty, using SSH under Linux and using OpenSSH for Windows, we should go in this (second) part of the series on how to basically secure the OpenSSH server.
Change default port
First, we should change the port on which the server is running OpenSSH. But why? This is a classic case of security through obscurity. Theoretically this does not change the level of security. Practically, however, you can recognize that the number of attacks to the SSH server falls. This is because many attackers only scan on port 22, the default SSH port. If we change the port, we get out of the scanners scope. Sure, someone who has specifically chosen our server as an attack object, can still perform a port scan, but nevertheless it’s worth the effort, to exclude the just mentioned “haphazard” scanners.
To change the port, we need to make a change in the sshd_config of the OpenSSH server. Therefore open a terminal/shell on your computer which is running your OpenSSH server.
sudo vim /etc/ssh/shhd_config
Now search for “Port 22” inside the sshd_config and change the line to “Port X”. (Where X is a port of your choice.) But be careful when choosing the port – don’t select one that is already in use! If you’ve running, for example, a web server on port 80, then port 80 is logically not the port of choice for your OpenSSH server.
After you’ve adjusted the port, you have to save the changes, close the sshd_config and restart the OpenSSH service.
sudo service ssh restart
Note: Those of you who are unfamiliar with VIM and it’s handling, can also replace the “vim” with a “nano” in all of the snippets in this tutorial.
Increase the SSH LogLevel
Thus, the OpenSSH server logs erroneous applications and potential attacks, we need to adjust the log level. This also has to be done inside the sshd_config.
sudo vim /etc/ssh/shhd_config
By default the OpenSSH server logs on a very low detail level. If you suspect, that the service is under “attack” or you would like to have detailed logs, you have to raise the LogLevel in the sshd_config. For this purpose, the following line has to be adjusted.
#old LogLevel INFO #new LogLevel VERBOSE
As with the port change, the OpenSSH service needs to be restarted after saving the changes.
sudo service ssh restart
If the log level is set to “VERBOSE” the OpenSSH server writes the logs to “/var/log/auth.log”.
To have a quick look at any failed login attempts, the following command can be helpful.
cat /var/log/auth.log | grep "Failed"
(Note: The above command can only be a assistance but not a full replacement for a detailed look at the logs.)
Disallow root login
Another way to secure the OpenSSH server is to forbid to login as “root” and possibly even allow only certain users. Also again this changes must be made in the sshd_config.
sudo vim /etc/ssh/shhd_config
In order to suppress the login as root, the directive “PermitRootLogin” has to be adjusted.
#old PermitRootLogin yes #new PermitRootLogin no
If the directive is set to ‘no’, no one can log in as root anymore. Nevertheless, there are cases when you need root privileges. At that point you can acquire the needed root privileges after login by using the “su” or “sudo” command.
Create an user whitelist
Another possible step to secure a SSH server is to create a white list of allowed users. If you want that only the user(-accounts) “raffael” and “peter” are able to login, you must add the following line into the sshd_config.
AllowUsers raffael peter
(If the directive AllowUsers already exists inside the sshd_config, it must of course be adapted and not inserted a second time.)
Even if you know that a particular user has a fix IP address (which in DSL connections, unfortunately, is mostly not the case), you can make the whitelist even more restrictive.
AllowUsers raffael@192.168.2.100
The above IP address has to be replaced by the user’s one and is used here only as an example. The construction of the rules is done by specifying a host according to the following scheme: user@host.
Conclusion
That already was the second part of my article series concerning OpenSSH. In the third part I will be covering the login procedure by using the private/public key method. Who wants to know what has happened so far, is welcome to also take a look at the first part of the article series.
