Hardening ssh guide

Strengthening — Enhancing SSH

It's worth noting that in this article, the search was performed on port 22, which is the default port for the SSH service.

The SSH service is perfect for maintaining the confidentiality and integrity of data exchanged between systems. In addition to this, one of its main advantages is server authentication using public key.

So this time, we'll make some configurations to enhance the security of this widely used remote administration service.

Most of the changes are made in the /etc/ssh/sshd_config file.

1. Always use public key SSH authentication

The OpenSSH server supports various authentications. We recommend using public key authentication. To do this, you need to create the key pair using the following link from the folks at Digital Ocean, which shows you how to create the key pair and add it to the server.

2. Change the default port

Most attacks on this service occur from automated tools trying common usernames and passwords on port 22.

If you change the port, you'll avoid most of these types of attacks.

3. Limit IP binding

The ListenAddress directive specifies on which IP addresses the port will be opened to provide the service. If the system has more than one IP address, whether IPv4 or IPv6, it is advisable to limit this listening only to the necessary ones. By default, it comes as ALL, so the service will open on all available interfaces of the system.

4. Disable ROOT user for login

The system administrator should not authenticate directly against the machine. It is recommended to modify this parameter to set it to "no"

5. Limit SSH access for system users

AllowUsers enables which users are allowed to use the SSH service. You can list several users. By default, it allows all system users to log in via SSH, but it is recommended to limit access only to those who really need to use this service.

Like with AllowUsers, AllowGroups allows specifying the group or groups of users allowed to access the system via SSH.

6. Disable password-based login

All password-based logins should be disabled. Only allow logins based on public keys.

In some old versions of SSHD, it would be like this:

7. Disable empty passwords

We must reject remote logins from accounts with empty passwords.

8. Limit failed authentication attempts

The MaxAuthTries parameter specifies the maximum number of failed authentication attempts per connection. We recommend setting it to a value like 3.

9. Adjust LoginGraceTime

This directive specifies how many seconds a user is allowed to remain with an open connection without having authenticated correctly. We recommend this value to be, for example, 60.

10. Limit simultaneous unauthenticated connections

With this directive, MaxStartups specifies the maximum allowed number of simultaneous unauthenticated connections. All subsequent connection attempts will be denied until one of the previous ones completes the entire process successfully.

This way, we can deny possible brute-force attacks. By default, it comes as 10, and we recommend setting a lower value, for example, "3".

11. Enable a warning banner for SSH users

Specifies the file that will be shown before a user authenticates on the system.

12. Configure the inactive session timeout interval

An inactive time interval can be set for SSH sessions. This way, if a user leaves the session unattended, it will automatically close after the specified time.

13. Disable .rhosts files

SSH can emulate the behavior of the obsolete RSH command; simply disable insecure access via RSH.

14. Disable host-based authentication

It is advisable to disable this option since we initially defined that authentication would be by public key.

15. Disable X11forwarding

X11 is the graphical server used by almost all Linux distributions. This server allows, among other things, forwarding through SSH. This means that it is possible to run graphical applications from a remote machine by exporting the display to our local desktop. In other words, the application runs on the remote server, but we view the graphical interface on our local desktop.

So, if you don't need to use this graphical server, it's better not to have it enabled.

16. Chroot (Lock users to their home directories)

By default, users can navigate through the server's directories, such as /etc /, /bin, among others. SSH can be protected by using Chroot to lock users into their personal directories.

We will show this configuration in a new article soon.

17. Configuration check

To check the configuration file and detect any errors before restarting SSHD, run:

Finally, it is important to consider that access to this service can be limited only to the organization's LAN or through a VPN for cases requiring external access.