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:
Linux: /etc/ssh/sshd_config
MAC: /etc/ssh/sshd_config
Windows: %programdata%\ssh\sshd_config
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:
Recommended Configuration:
PermitRootLogin no
Disabling Root Login is a good security practice. Allow users with normal or sudo privileges should be allowed to connect.
Maximum login attempts:
Recommended Configuration:
MaxAuthTries 3
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:
Recommended Configuration:
PasswordAuthentication No
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
PermitEmptyPasswords No
If a user does not use any password, it should not be allowed to connect through SSH.
SSH Public Key Authentication:
Recommended Configuration:
ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no
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:
Recommended Configuration:
PubkeyAuthentication yes
You should use Public and Private key pairs for authentication.
Disable X11 Forwarding:
Recommended Configuration:
X11Forwarding no
This feature should be disabled to minimize the attack surface.
Restrict Access to Specific Users:
Recommended Configuration:
AllowUsers *@192.168.1.1
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:
Recommended Configuration:
StrictHostKeyChecking ask
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.
Additional Recommendations:
AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no
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.
