Linux OS: Hardening Your SSH Server

Hardening SSH connection illustration

    Good day everyone! Today, I would like to share a tutorial on how to harden your SSH connections for improved server security. In this guide, we will cover various techniques and best practices to ensure that your SSH connections are robust and protected against potential threats.

Securing/hardening your SSH server is crucial for protecting your system from unauthorized access. The sshd_config file, which governs SSH daemon settings, is your first line of defense. This article outlines essential configurations to enhance the security of your SSH server.

Back Up Your sshd_config File

Before making any changes, it is essential to create a backup of the original sshd_config file. This ensures that you have a safe copy to restore if anything goes wrong during the configuration process.

You can create a backup using the following command:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

This command copies the original sshd_config file and saves it as sshd_config.bak in the same directory (/etc/ssh). Having this backup allows you to quickly revert to the original settings in case of errors or misconfigurations, helping to maintain the security and accessibility of your SSH service.

Edit The sshd_config File

To edit the sshd_config file, you can use a text editor of your choice. Personally, I prefer the Vim editor as my standard. However, if you’re unsure which editor is the easiest for you to use in the Linux terminal, feel free to choose any editor you’re comfortable with.

To open the sshd_config file with Vim, run the following command:

sudo vim /etc/ssh/sshd_config

This command uses sudo to ensure you have the necessary permissions to edit the file.

Hardening The SSH Server

# SSH Configuration File

# /etc/ssh/sshd_config

# 1. Disable SSH protocol 1 (only use protocol 2)

Protocol 2                     # Use only SSH protocol version 2

# 2. Change the default SSH port (optional)

Port 8022                     # Change from 22 to a non-standard port to reduce automated attacks

# 3. Disable root login

PermitRootLogin no             # Prevent direct login as the root user

# 4. Disable password authentication

PasswordAuthentication no      # Use SSH keys for authentication instead

# 5. Enable public key authentication

PubkeyAuthentication yes       # Ensure public key authentication is enabled

# 6. Allow only specific users

AllowUsers yourusername        # Replace 'yourusername' with your actual user(s)

# 7. Limit user groups (optional)

AllowGroups sshusers           # Replace 'sshusers' with your allowed group(s)

# 8. Enable logging

SyslogFacility AUTH            # Log SSH login attempts

LogLevel INFO                  # Set log level to info for more detailed logs

# 9. Set idle timeout interval

ClientAliveInterval 300        # Time in seconds to wait before sending keepalive messages

ClientAliveCountMax 0          # Disconnect clients that do not respond to keepalive messages

# 10. Disable X11 forwarding (if not needed)

X11Forwarding no               # Disable X11 forwarding for security

# 11. Enable TCP keepalive (optional)

TCPKeepAlive yes               # Keep TCP connections alive

# 12. Use strong ciphers and MACs (optional)

Ciphers aes256-ctr,aes192-ctr,aes128-ctr

MACs hmac-sha2-256,hmac-sha2-512

# 13. Set login grace time

LoginGraceTime 60              # Time allowed for a user to log in (in seconds)

# 14. Configure the SSH banner (optional)

Banner /etc/issue.net          # Display a banner upon login (create this file as needed)

# 15. Use the `Match` block for specific configurations (optional)

Match User yourusername        # Apply settings specifically for a user

ForceCommand internal-sftp   # Force SFTP only access for that user

 

Let’s break down the configurations line by line to understand their purpose and implications:

1. Protocol 2

Protocol 2

SSH has two versions: Protocol 1 (old and insecure) and Protocol 2 (modern and secure). Always use Protocol 2 because it protects your connection with better encryption. It’s like choosing the safest lock for your door.

2. Port 8022

Port 8022

SSH normally uses port 22, which hackers know to target. Changing it to something like 8022 makes your server less obvious to attackers. It’s a small trick to avoid unwanted attention, but remember to update your firewall.

3. PermitRootLogin no

PermitRootLogin no

Logging in as root (the most powerful user) directly is risky. By disabling root login, you force users to log in with regular accounts first and then elevate their permissions. This adds an extra layer of security, preventing attackers from directly accessing the most powerful account.

4. PasswordAuthentication no

PasswordAuthentication no

By setting PasswordAuthentication to no, you disable the ability to log in using just a username and password. This means that users must use more secure methods, like SSH keys, to connect to the server. SSH keys are like having a unique key for your door, making it much harder for attackers to gain access since they can't simply guess passwords.

5. PubkeyAuthentication yes

PubkeyAuthentication yes

Setting PubkeyAuthentication to yes enables the use of SSH keys for logging into your server. SSH keys are pairs of cryptographic keys: a public key that you place on the server and a private key that you keep secure on your local machine.

When you try to connect, the server checks if your public key matches your private key. If they match, you gain access without needing to enter a password. This method is much more secure than using passwords alone because it’s nearly impossible for attackers to guess your private key.

6. AllowUsers yourusername

AllowUsers yourusername

The AllowUsers directive specifies which users are permitted to log in to your server via SSH. By setting this option to a specific username, like yourusername, you restrict access to only that user. This means no one else can connect to the server using SSH, even if they have valid accounts:

AllowUsers janis

This approach enhances security by limiting access to trusted individuals, making it much harder for unauthorized users to attempt to log in.

7. AllowGroups sshusers

AllowGroups sshusers

The AllowGroups directive limits SSH access to specific user groups. For example, if you want only users in the group sshusers to connect, you would add:

AllowGroups sshusers

This adds an extra layer of security by preventing users not in that group from logging in.

8. SyslogFacility AUTH and LogLevel INFO

SyslogFacility AUTH and LogLevel INFO

The SyslogFacility AUTH and LogLevel INFO options enable detailed logging of SSH activities. This helps you monitor login attempts and identify any suspicious activity on your server.

9. ClientAliveInterval 300 and ClientAliveCountMax 0

ClientAliveInterval 300 and ClientAliveCountMax 0

Here, the server will wait 300 seconds (5 minutes) before sending a keepalive message. If the client does not respond, it will be disconnected. This helps free up resources and reduces the risk of stale connections.

A value of 0 means that the server will immediately disconnect a client if it does not respond to the first keepalive message. This ensures that the server does not maintain connections to unresponsive clients, enhancing security by closing unused sessions.

10. X11Forwarding no

X11Forwarding no

The X11Forwarding no option disables X11 forwarding, which allows GUI applications to run remotely. If you don't need this feature, disabling it reduces the attack surface for potential vulnerabilities.

11. TCPKeepAlive yes

TCPKeepAlive yes

The TCPKeepAlive yes setting keeps TCP connections alive by sending periodic messages. This helps prevent disconnections due to network issues, ensuring more stable connections.

12. Ciphers aes256-ctr,aes192-ctr,aes128-ctr and MACs hmac-sha2-256,hmac-sha2-512

Ciphers aes256-ctr,aes192-ctr,aes128-ctr and MACs hmac-sha2-256,hmac-sha2-512

The Ciphers and MACs directives specify the encryption methods and message authentication codes to use. Using strong ciphers and MACs enhances security by making it harder for attackers to intercept and decrypt communications.

13. LoginGraceTime 60

LoginGraceTime 60

The LoginGraceTime directive specifies how long a user has to log in before the server disconnects them. Setting this to 60 seconds helps prevent brute-force attacks by limiting the time available for password guessing.

14. Banner /etc/issue.net

Banner /etc/issue.net

The Banner option displays a message upon login. You can create a banner file to display legal notices or security warnings, reinforcing security awareness among users.

15. Match User yourusername and ForceCommand internal-sftp

Match User yourusername and ForceCommand internal-sftp

The Match block allows you to set specific rules for individual users. This configuration would force the user yourusername to use SFTP only, restricting their access to the server's shell and enhancing security.

End...

Thank you for taking the time to explore today's tutorial on hardening your SSH server. I appreciate your visit and hope the information provided was valuable. Wishing you a productive and secure day ahead!