Secure Shell (SSH) is a network protocol used to connect devices over the internet via a terminal. It is also used to share files between two remote devices securely. SSH is widely used since it encrypts the data that is being transferred, therefore protecting it from malicious actors. This blog post will cover SSH recommended configurations for enhancing its security and preventing known vulnerabilities.
SSH uses advanced hashing algorithms such as AES, 3DES, etc to encrypt the data before sending it, and works on port number 22 by default. Due to its security SSH is widely accepted and used to access computers remotely to execute commands. SSH uses different authentication methods including password-based authentication, key pair authentication, and a mix of both. However, SSH cannot fix all TCP problems since it runs over the application layer of the OSI model.
SSH Config Recommendations:
You can find the saved SSH configuration in the following files:
The config file can be edited to change the SSH configuration. Recommended configuration for SSH servers may vary between organizations according to their specific requirement. However, some best practices should be kept in mind while configuring the SSH server.
SSH Port 22:
SSH is configured by default to use Port 22. Port 22 is known to be an easy target for attackers to perform a Man-in-the-Middle attack leveraging the port’s structural weaknesses. Therefore, you must change the SSH port to some arbitrary port.
SSH Protocol 2 vs 1:
SSH protocol 2 is more secure than Protocol 1, therefore it should be changed. A design flaw in protocol 1 allows a malicious server to establish two parallel sessions, using the same session ID. As a result, attackers can perform a Man-in-the-Middle attack.
SSH permit root login:
Disabling Root Login is a good security practice. Allow users with normal or sudo privileges should be allowed to connect.
Maximum login attempts:
This value defines how many failed login attempts are permitted per user before blocking his access for a certain amount of time. The number of trails may vary according to the organization’s needs.
SSH Password Authentication:
The password authentication method is a hub for Brute Force attacks. Therefore, we recommend not using this type of authentication method.
Prevent Connection with Empty Password
If a user does not use any password, it should not be allowed to connect through SSH.
SSH Public Key Authentication:
SSH servers are usually configured to use only public key authentication. SSH supports many other authentication methods. Public key authentication should only be used if necessary.
SSH Public and Private Key Authentication:
You should use Public and Private key pairs for authentication.
Disable X11 Forwarding:
This feature should be disabled to minimize the attack surface.
Restrict Access to Specific Users:
This feature should be used if ssh server needs to be accessed only from a specific IP address. Any other IP address request will be rejected.
Protect SSH Traffic With Server’s Fingerprint:
This option requires verification using the fingerprint of the server before the communication is approved. This can help to reduce the chances for Man-in-the-Middle attacks and IP spoofing.
This is only a partial list. Each organization should build a hardening and secured configuration policy that includes SSH configurations in it. It is important to remember you can’t just change your SSH setting without testing the change’s impact on your production. Doing so can end with having SSH that doesn’t work or causing production outages.
We strongly recommend using hardening automation tools, that will automatically generate an impact analysis report and enforce your policies on production. Using such tools will win you the best chances for achieving a hardened infrastructure in minimum effort, time, and risk for downtimes.