Securing SSH access

Why is SSH Security More Important Than Ever?

If you have a Linux server, you can be almost certain that automated scripts are trying to log into it via SSH right now. These brute force attacks, often carried out using long lists of usernames and passwords, are clearly visible in the logs at /var/log/auth.log or /var/log/secure. But the good news is that with a few simple and principled settings, you can significantly raise the security level of SSH and render these attempts ineffective.

In this article, we provide a practical, step-by-step path for securing SSH on a Linux server (Debian/Ubuntu and RHEL/CentOS-based distributions). Our focus is on four key actions: changing the default port, using public key authentication instead of passwords, restricting allowed users, and installing fail2ban. Perform these steps in order to ultimately have a server resistant to automated attacks.

Step One: Changing the Default SSH Port

Port 22 is the standard SSH port, and all scanners and bots target this port first. Changing the port to an unusual number drastically reduces the volume of automated attacks. This is a "security by obscurity" layer, but it is very effective in practice because most malicious scripts only check port 22.

How to Change the Port

Open the SSH configuration file with your preferred editor:

sudo nano /etc/ssh/sshd_config

Find the following line and change its value (for example, to port 2222):

Port 2222

If the Port line does not exist, add it at the beginning of the file. Then restart the SSH service:

sudo systemctl restart sshd

Important: Before closing your current session, open a new session with the new port and make sure you can connect. If you have a firewall (such as UFW or firewalld), be sure to open the new port:

sudo ufw allow 2222/tcp

Common Mistake: Forgetting the Firewall

Many users, after changing the port, forget to open the new port in the firewall and effectively lock themselves out of their server. Always add the firewall rule before restarting the service, and after the change, test the new connection. If you get locked out, use the web-based console from your hosting provider (such as VNC or Serial Console) to revert the settings.

Step Two: Public Key Authentication Instead of Passwords

Passwords, even the strongest ones, are vulnerable to brute force attacks and social engineering. SSH public key authentication uses a cryptographic key pair (public and private) that provides much higher security. The private key stays on your system, and the public key is placed on the server. This way, you log in without a password using a 2048 or 4096-bit key.

Generating the Key and Transferring It to the Server

On your local system (laptop or personal computer), run the following command:

ssh-keygen -t ed25519 -C "your_email@example.com"

The ed25519 algorithm is fast, secure, and modern. If your server does not support it (it is very old), use rsa -b 4096 instead. After generating the key, transfer the public key to the server:

ssh-copy-id -p 2222 user@your_server_ip

This command adds your public key to the ~/.ssh/authorized_keys file on the server. Now log in with the following command and make sure it works without a password:

ssh -p 2222 user@your_server_ip

Disabling Password Authentication

After confirming the key works, disable password authentication. In the sshd_config file, set the following lines:

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

Note: Only set UsePAM no when you are sure your key works; otherwise, you might get locked out. After the changes, restart the service:

sudo systemctl restart sshd

Common Mistake: Closing the Door Before Testing the Key

Never apply PasswordAuthentication no before fully testing the public key. Keep an open SSH session, log in from another terminal with the key, and then apply the change. If your key is corrupted or the file path is wrong, you will be locked out of the server.

Step Three: Restricting Allowed Users

Even with public key authentication, it is better to restrict SSH access to specific users. This reduces the attack surface, and if one of the system users is compromised, the attacker cannot use the same credentials to log in.

Using AllowUsers and AllowGroups

In the sshd_config file, you can specify the list of allowed users or groups:

AllowUsers admin developer
AllowGroups sshusers

If you are using a group, first create the group and add the user to it:

sudo groupadd sshusers
sudo usermod -aG sshusers admin

Note that if you set both AllowUsers and AllowGroups, the user must satisfy both conditions. Usually, it is better to use only one of them.

Restricting Root Access

Direct login as the root user via SSH carries a high risk. It is better to disable it and log in with a regular user, then use sudo to run administrative commands. In the configuration file:

PermitRootLogin no

If for some reason you need root login, at least restrict it to public key authentication only:

PermitRootLogin prohibit-password

Common Mistake: Forgetting Service Users

If you have users like www-data or mysql on your system, make sure they are not in the AllowUsers list. These users typically have disabled shells and should not be allowed SSH access. You can check user shells with the following command:

grep -E "www-data|mysql" /etc/passwd

Step Four: Installing and Configuring fail2ban

fail2ban is a powerful tool that monitors system logs and blocks the attacker's IP address for a specified period after several failed attempts. This tool is highly effective against brute force attacks on SSH.

Installing fail2ban

On Debian/Ubuntu:

sudo apt update
sudo apt install fail2ban -y

On RHEL/CentOS:

sudo yum install epel-release -y
sudo yum install fail2ban -y

Configuring for SSH

Create the local configuration file:

sudo nano /etc/fail2ban/jail.local

Add the following content:

[sshd]
enabled = true
port = 2222
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600

Explanation of parameters:

• maxretry: The number of failed attempts before being blocked (here, 3 times).
• bantime: The duration of the ban in seconds (here, 1 hour).
• findtime: The time window in which attempts are counted (here, 10 minutes).
• logpath: The log file path. On RHEL/CentOS, it is usually /var/log/secure.

Restart the service:

sudo systemctl restart fail2ban
sudo systemctl enable fail2ban

Checking Status and Managing Bans

To see the jail status and blocked IPs:

sudo fail2ban-client status sshd

To manually remove an IP from the ban list:

sudo fail2ban-client set sshd unbanip 192.168.1.100

Common Mistake: Wrong Log Path

If fail2ban is not working, the first thing to check is the logpath. On systemd-based distributions, the SSH log may be in /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL/CentOS). Find the exact path with the following command:

sudo grep "sshd" /var/log/auth.log | tail -5

If the log is empty, the SSH service is probably using journald, and you need to change logpath to /var/log/journal or use journalctl.

Additional Measures for SSH Security

The four steps above are the main foundation of SSH security, but a few other measures can further enhance your security:

Setting an Idle Timeout

Automatically disconnect SSH sessions that have been idle for a long time. In sshd_config:

ClientAliveInterval 300
ClientAliveCountMax 2

These settings send a keep-alive request after 5 minutes of inactivity and disconnect the connection after 2 unanswered requests.

Using Non-Standard Ports with Caution

Changing the port to something like 2222 is good, but if you use well-known ports like 443 or 80, you might conflict with other services. Choose a port in the range of 1024 to 65535 that is less commonly used.

Regular Log Monitoring

Periodically review SSH logs to detect unusual patterns early:

sudo grep "Failed password" /var/log/auth.log | tail -20

If you see a large number of failed attempts from one IP, fail2ban is probably not working correctly, or you have misconfigured it.

Conclusion

SSH security is a multi-layered process, and no single measure is sufficient on its own. Changing the port, using public key authentication, restricting users, and installing fail2ban are the four main pillars of this security, which we have practically reviewed in this article. Apply these changes in order and with care, and always test the new connection before closing the current session.

If you are looking for a secure and managed infrastructure to host your services, ServerNet offers various options for cloud services and hosting that you can confidently rely on. But remember, security is a shared responsibility; even on the best infrastructure, you must take your SSH settings seriously.

By implementing these steps, your server will become resistant to automated and brute force attacks, and you can focus on your core work with greater confidence.