Introduction

One of the strongest points of Unix-family systems is remote management. It doesn't matter whether the machine is next to us or across the ocean. After connecting to our server we get the impression as if we were sitting right in front of our server's monitor.

Years ago the standard method of access was the telnet protocol. The main flaw of this protocol, which disqualifies it, is unencrypted communication between hosts. This means that anyone who installs a so-called sniffer along the connection route will see all our communication, i.e. username, passwords, commands, and their results.
An alternative to telnet is the ssh protocol, which, unlike telnet, is fully encrypted. However, the default configuration of an ssh server isn't perfect - there are a few simple things that can significantly raise the security level.

We'll make changes mainly in the ssh configuration file: /etc/ssh/sshd_config, and of course after making changes we restart the ssh service.

Protocol version

All modern ssh installations have version 2 set by default, which, among other things, eliminates man in the middle attacks, but it doesn't hurt to check:

Protocol 2

Changing the port

For this, see: changing the ssh port

Blocking remote login to the root account

PermitRootLogin no

By default OpenSSH allows direct login to the administrator account. This is dangerous, because compromising one password is enough to gain full control over the server. It's a much better idea to log in as a regular user, and only later switch to the root account using the su command.

Limiting the number of login attempts

MaxAuthTries 3

This option specifies the number of password entry attempts we can make during a connection. Once this limit is exceeded, the connection is dropped. When considering this option, I recommend: Installing and configuring Fail2Ban

Restricting ssh access for users / groups

By default, anyone with shell access can log into the server. We can change this using the options: AllowGroups, DenyGroups, AllowUsers, DenyUsers. Of course you can add several users or groups as you see fit, separating them with a comma or space.

Restricting ssh access by IP address (TCP Wrappers)

If we can afford such a restrictive security policy, it's worth using. The condition is that ssh be compiled with support for the libwrap library. Most likely it is, but you can always check:

# whereis ssh
ssh: /usr/bin/ssh /etc/ssh /usr/share/man/man1/ssh.1.gz
# ldd /usr/sbin/sshd | grep libwrap
libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x000061fbfb994000)

TCP Wrappers uses access rules stored in the files /etc/hosts.allow and /etc/hosts.deny. When creating rules you need to remember at least a few things. The first issue is important, because we can easily cut off ssh access ourselves. We must always check whether the file ends with a newline character - if in /etc/hosts.allow we have no entry regarding ssh, and in the /etc/hosts.deny file we have some IP address and forget the "enter", we won't be able to log in via ssh from any address.
When creating rules we must take into account the order in which the files are processed. /etc/hosts.allow is processed first, and only afterwards /etc/hosts.deny. That's why, if we have a rule regarding ssh in this particular case in /etc/hosts.allow, the rule in /etc/hosts.deny will be ignored.

# /etc/hosts.deny: list of hosts that are _not_ allowed to access the system.
#                  See the manual pages hosts_access(5) and hosts_options(5).
#
# Example:    ALL: some.host.name, .some.domain
#             ALL EXCEPT in.fingerd: other.host.name, .other.domain
# ALL: PARANOID

sshd : ipAddress, ipAddress :spawn /bin/echo Login attempt `/bin/date` from %h >> /var/log/ssh.log

Above we're blocking two IP addresses, and optionally logging the login attempt to a file. Similarly, we create rules in /etc/hosts.allow. In the ipAddress field, instead of single IP addresses, we can use subnet addresses in the form: 192.168.1.0/255.255.255.0 or 192.168.1. as well as domain names.

After adding rules and saving the changes to the files, nothing needs to be restarted anymore.