Internet connected services, like SSH, receive nowadays a lot of bogus connections. Without restricting access to the server, the it will loose performance due to the amount of authentication and authorization requests sent from the internet. Without certain amount of SSH restrictions connecting abusers will use all locally assigned or available resources to get access to host, in worst case this kind of brute-force might go on for days, weeks, months and eventually the attackers might get access to the host.

There are 2 ways to define the type of access allowed to the service, it applies to many other services as well:

• Usage of internal openssh service settings, f.e.: specifying configuration options, f.e. Port 4711
• Usage of external tools, external to openssh, and any other service, f.e.: iproute2 or sshguard or iptables

Below a list of techniques to minimise the risk of abuse of the SSH service:

Internal tools, native tools:

• setting standard SSH TCP port from 22 to other port f.e.: 4321
• binding the service tor run only one IP address, and/or one IP address family f.e.: IPv4 only
• restricting the key exchange algorithms and ciphers to only few desirable
• assigning users to groups which are allowed to use the SSH dial-in
• setting limits for the amount of assigned VTY's and authentication sessions
• generating authentication keys for hosts, key based authentication

External tools, system tools:

• using a brute-force detecting tool to automatically drop SSH attacks, f.e.: sshguard or fail2ban
• configuring an IP access-list from which an authorization request is allowed f.e.: iptables nftables (whitelisting)
• blackhole routing of IP ranges by using iproute2 (blacklisting)
• using port-knocking for SSH access f.e. with the knockd daemon
• deploying 2FA (2 factor authentication) for SSH access

By setting only a few of the internal OpenSSH configuration options, it is possible to reach a good enough service security. It is more efficient and elegant to define a connection service with strictly predefined parameters, right at the source of the service. By minimising the amount of accepted key exchange algorithm to only one, and restricting the cipher also to only one, only specific hosts meeting the requirements will be able to authenticate to the server.

The ciphers openssh is currently using for outbound/inbound connections can be listed with following command:

Authentication specific ciphers which OpenSSH is using during the authentication/authorization phase, can be shown using following command:

Only 3 algorithms can be used during the key exchange phase.

Configuration steps of the /etc/ssh/sshd_config file, defining only specific ciphers which will be accepted by the server:

[...]
# Ciphers and keying
KexAlgorithms curve25519-sha256@libssh.org
Ciphers chacha20-poly1305@openssh.com
[...]

Setting the maximal amount of authentication retries from a source, and limiting the amount of available VTY sessions:

[...]
MaxAuthTries 3
MaxSessions 3
[...]

Defining a specific system group allowed to use the SSH service, in this example the group is called ssh-access. All users authenticating via SSH to this host must belong to this specific group:

[...]
AllowGroups ssh-access
[...]

Using only one IP address family, here IPv4 and setting a non standard TCP port < 1024 to use for incoming SSH sessions:

[...]
Port 4711
ListenAddress 0.0.0.0
# Listen on 1 IP and address family:    
# ListenAddress 192.0.2.10

By changing only a few lines in the openssh daemon configuration file, the service is secured by minimising the amount available connection options.

Each configure step done on the SSH server, should be verified from far-end host using the verbose function of ssh:

Increasing verbosity, by setting -vvvv option, using maximal verbose level 4:

Each configuration step listed above should be considered and configured carefully, especially if using the in-band connection, means if configuring the link or the service via the SSH session is running currently over. Failure will result in manually resetting the service on-site.

A configured service running within predefined parameters is a efficient and effective way to minimise abuse of a service. This applies to all services operated in a network.