Hardening a SSH Server

An SSH access is a privileged entry point for hackers. Today I am offering you a guide that will allow you to strengthen the security of your SSH accesses, to reduce the attack surface, in order to make them much more difficult to attack.
Don't try this at home
The technical indications given in this article are intended to restrict access to your server. Make sure you have temporary secondary access to check that the configurations you have put in place have not cut off all your access! I recommend that you experiment on a test server before doing it in production.
To start modifying the file (to be adapted to your editor) :
vi /etc/ssh/sshd_config
Reminder: to activate each of these configurations, a restart of the SSH service is necessary.
Modify the SSH default port
Modifying the default port makes it possible to get rid of all the scripts that test the default ports to discover breaches to open on our system. It is therefore relevant to modify it with a randomly chosen port.
Port 8645
Disable Passwordless Authentication
This is one of the essential rules in computer security: an account without a password must not be able to identify itself remotely on the system!
PermitEmptyPasswords no
Disable authentication as root
Like disabling passwordless authentication, the root account should not be able to log in remotely.
PermitRootLogin no
Restrict access to defined users or groups
Based on the principle of least privilege, the restriction by user or by user group makes it possible to perfectly control the accounts authorized to connect to the server without having to systematically edit the configuration file (less manipulation, less risk of errors ).
AllowUsers user1 user2 ...
AllowGroups group1 group2 ...
Set the lifetime of an inactive session
Cutting inactive connections or connections whose client has not responded for some time is also a parameter to be modified downwards in order to disconnect inactive users. In general, I put a disconnection after 1200s (20min) of inactivity. Here are the settings to apply:
ClientAliveInterval 1200
ClientAliveCountMax 0
Every 1200s, the server will send a test message to the client to know if it is still active. If the client is idle, it increments the ClientAliveCount by 1. When the value of ClientAliveCountMax is reached, the client is considered idle and the session disconnected.
Set authentication timeout
The almost systematic use of remote connection tools reduces the time required to establish the SSH connection to a few seconds. This parameter is not necessarily essential but personally I reduce the delay to 20 seconds.
LoginGraceTime 20
Disable use of SSHv1 and force use of SSHv2
Imperative to force a greater level of security.
Protocol 2
Disable X11 forwarding
Potential vector of attacks if the server is corrupted, it is necessary to deactivate it.
X11Forwarding no
Disable SFTP subsystem
Frequent attack vector, if you do not use the FTP layer of SSH I invite you to deactivate it. Just comment out the line.
#Subsystem sftp /usr/lib/openssh/sftp-server
Protection against brute force hacking attempts
Considering the fact that we almost always use login software with saved parameters, it is possible to reduce the number of failed attempts before blocking enormously.
MaxStartups 5:30:20
5: Number of connection attempts from which the server begins to refuse connections.
30: Percentage of chance that the server automatically refuses the connection once the 5 attempts have been reached (increments by 10 in 10).
20: Maximum number of failed attempts from which the server blocks everything.
The final word
Here is already a good series of modifications to be made to properly secure your SSH server.
Another approach is also to secure all open ports on your server via third-party tools such as PortSentry, FailtoBan, log auditing, etc.
There is also a great way to protect SSH to deal with: authentication using a private key. This configuration, which is a bit long and tedious, will be the subject of a future article.
0 comments