8 SSH Hardening Tips to Secure a Linux Server Against Brute-Force Attacks

SSH is one of the most common ways to manage Linux servers remotely. It is also a common target for automated password-guessing attacks.

An SSH server exposed to the internet can receive repeated login attempts from automated scanners. Attackers may try common usernames, weak passwords, leaked credentials, or password combinations based on known information.

You can reduce this risk by hardening the SSH server, using strong authentication, limiting login attempts, and monitoring failed connections.

This guide covers eight practical SSH hardening tips for Linux. The goal is to reduce unnecessary access, strengthen authentication, and make automated attacks less effective.

What Is an SSH Brute-Force Attack?

An SSH brute-force attack is an attempt to gain access to a server by repeatedly trying usernames and passwords.

Attackers usually automate these attempts. A script can try many common usernames and passwords without manual interaction.

Common targets include:

• root
• admin
• user
• Default usernames
• Weak or reused passwords

A server exposed directly to the internet can receive automated SSH login attempts even if nobody is specifically targeting it.

The goal of SSH hardening is simple: make unauthorized access harder and reduce the number of useful attack opportunities.

8 SSH Hardening Tips to Defend Your Linux System Against Password Attacks

As a Linux administrator, you can secure your Linux servers against SSH brute-force attacks in many ways:

• Use long, unique passwords where passwords are required.
• Prefer SSH public-key authentication for server access.
• Do not allow unnecessary users to log in through SSH.
• Limit authentication attempts.
• Add controls such as Fail2ban to respond to repeated failed connections.
• Keep OpenSSH and the operating system updated.
• Monitor SSH authentication logs.

A strong password helps, but SSH hardening adds another layer of protection by controlling how authentication can be attempted.

Enough said. In the following sections, we will learn how to apply these protections on a Linux server.

Following are the 8 essential SSH security hardening tips I'd recommend to defend your Linux system against password brute-force attacks.

1. Keep OpenSSH Updated

Security problems can affect OpenSSH and the operating system around it. Keeping your Linux packages updated is one of the simplest security improvements you can make.

On Debian or Ubuntu:

sudo apt update
sudo apt upgrade

On Fedora, RHEL, and compatible systems:

sudo dnf upgrade

You can check the installed OpenSSH client version with:

ssh -V

For the SSH server version, you can also check the installed package using your distribution's package manager.

Do not rely only on the OpenSSH version number when checking security. Linux distributions often backport security fixes to older package versions.

Tip: Enable your distribution's normal security update process instead of waiting months before updating a server.

2. Disable SSH Direct Root Login

Allowing direct SSH login as root gives an attacker a high-value username to target.

A better approach is to log in with a normal administrative account and use sudo when root privileges are required.

Open the SSH server configuration:

sudo nano /etc/ssh/sshd_config

Set:

PermitRootLogin no

Save the file.

Before applying the change, check the configuration:

sudo sshd -t

If there is no output, the configuration passed the syntax check.

Then reload SSH:

sudo systemctl reload ssh

On some distributions, the service is named sshd:

sudo systemctl reload sshd

Important: Keep your existing SSH session open while testing the new configuration. Do not close your only working administrative session until you confirm that a new login works.

Ubuntu also supports configuration files under /etc/ssh/sshd_config.d/, so check your distribution's SSH configuration before changing settings.

3. Use SSH Keys Instead of Passwords

SSH keys are generally a better choice than password-based authentication for server administration.

Generate an Ed25519 key on your local computer:

ssh-keygen -t ed25519

You can normally accept the default file location. Protect the private key with a passphrase.

Copy the public key to the server:

ssh-copy-id username@server

Then test the connection:

ssh username@server

Once key-based login works, you can disable password authentication.

Edit:

sudo nano /etc/ssh/sshd_config

Set:

PasswordAuthentication no

Then test the configuration:

sudo sshd -t

Reload SSH:

sudo systemctl reload ssh

Or:

sudo systemctl reload sshd

Important: Do not skip the testing step

Disabling password authentication before confirming that your SSH key works can lock you out of the server.

Keep your current SSH session open.

Open a second terminal and test:

ssh username@server

Only disable password authentication after the new key-based login succeeds.

For more details, check the following guide:

• How To Configure SSH Key-based Authentication In Linux

4. Restrict Which Users Can Use SSH

If every local user can attempt SSH login, the attack surface is larger than necessary.

OpenSSH lets you specify which users are allowed to connect.

For example:

AllowUsers senthil kumar

This permits SSH access only for senthil and kumar.

You can also control access using a group:

AllowGroups sshusers

Then create a group:

sudo groupadd sshusers

Add a user:

sudo usermod -aG sshusers senthil

Group-based access can be easier to manage when several administrators need SSH access.

For example, instead of changing the SSH configuration every time an administrator joins or leaves a team, you can manage membership of the sshusers group.

OpenSSH documents both AllowUsers and AllowGroups as access-control options.

Keep it simple: allow SSH access only for accounts that actually need it.

Related Read:

• How to Disable SSH Password Authentication for Specific User or Group

5. Limit SSH Authentication Attempts

You can also limit how many authentication attempts are allowed during a single connection.

In /etc/ssh/sshd_config, set:

MaxAuthTries 3

The OpenSSH default is higher, so lowering the value can reduce repeated attempts within one connection.

After changing it:

sudo sshd -t

Then reload:

sudo systemctl reload ssh

You can also configure MaxStartups, which controls unauthenticated SSH connections.

For example:

MaxStartups 10:30:60

This is more advanced and should be changed only when you understand the connection pattern of your server.

For most systems, start with the simpler MaxAuthTries setting.

Do not use extremely aggressive limits without testing them. Legitimate users can also make mistakes when entering credentials.

6. Install Fail2ban

Fail2ban is useful as an additional layer against repeated failed authentication attempts.

It monitors log files and can temporarily block IP addresses that repeatedly trigger authentication failures.

On Debian or Ubuntu:

sudo apt update
sudo apt install fail2ban

Enable the service:

sudo systemctl enable --now fail2ban

Check its status:

sudo fail2ban-client status

To check the SSH jail:

sudo fail2ban-client status sshd

Depending on your Linux distribution and Fail2ban configuration, the SSH jail may have a different name.

Fail2ban is not a replacement for strong authentication.

Think of it as another security layer:

SSH keys
   +
Restricted users
   +
Limited authentication attempts
   +
Fail2ban

Using several controls together is stronger than relying on one tool.

We recommend you to check our detailed article on Fail2ban configuration in the link below.

• How To Prevent SSH Brute Force Attacks Using Fail2ban In Linux

This comprehensive covers how to:

• Install Fal2ban,
• Configure Fail2ban,
• View enabled jails,
• Ban and unban IP addresses,
• Increase ban time,
• Whitelist good IP addresses,
• View logs,
• Configure Fail2ban with firewall,
• Configure email alerts,
• And when to and when NOT to use Fail2ban.

7. Test the SSH Configuration Before Reloading

A small configuration error can prevent SSH from working correctly.

Always check the configuration before applying changes:

sudo sshd -t

If the command returns no output, the configuration passed the syntax check.

If it reports an error, fix the problem before reloading SSH.

This is especially important after changing:

• PermitRootLogin
• PasswordAuthentication
• AllowUsers
• AllowGroups
• MaxAuthTries
• MaxStartups

After the syntax check succeeds:

sudo systemctl reload ssh

Or on systems using the sshd service name:

sudo systemctl reload sshd

Ubuntu's current OpenSSH documentation specifically recommends testing the configuration with sshd -t before restarting or reloading the service.

Keep one session open

This is one of the most important rules when hardening SSH remotely.

Do not make a change, immediately close your existing SSH session, and hope everything works.

Instead:

1. Keep the current session open.
2. Test the configuration.
3. Reload SSH.
4. Open a second terminal.
5. Test a new SSH connection.
6. Close the old session only after the new connection works.

8. Monitor Failed SSH Logins

Hardening SSH is not only about configuration. You should also know what is happening on the server.

System logs can show failed authentication attempts and other SSH events.

On systems using systemd, try:

sudo journalctl -u ssh

Some distributions use:

sudo journalctl -u sshd

To watch new entries as they appear:

sudo journalctl -f

You can also search for authentication failures:

sudo journalctl -u ssh | grep -i "failed"

The exact log location and service name vary between Linux distributions.

Regularly checking these logs can help you identify:

• Repeated failed logins
• Unknown usernames
• Unexpected source addresses
• Authentication problems
• Misconfigured clients
• Possible brute-force activity

If Fail2ban is installed, its status can also show whether addresses have been banned.

A Simple SSH Hardening Checklist

Before considering your SSH configuration hardened, check the following:

You do not need to apply every advanced SSH option you find online.

A small number of well-tested security controls is better than a complicated configuration that you do not understand.

Common SSH Hardening Mistakes

1. Disabling passwords too early

This is one of the easiest ways to lose access to a remote server.

Always test your SSH key before setting:

PasswordAuthentication no

2. Closing the current SSH session

Keep an existing administrative session open while testing changes.

If your new configuration fails, the existing session may give you a way to fix it.

3. Copying random SSH configurations

Do not paste a large sshd_config from a blog or forum without understanding it.

SSH settings can vary between Linux distributions and OpenSSH versions.

Change only what you need.

4. Treating Fail2ban as the main defense

Fail2ban is useful, but it should not be your only protection.

Strong authentication, restricted access, updates, and sensible SSH configuration should come first.

5. Using weak passwords for remaining accounts

Even if SSH key authentication is your main method, other services may still use passwords.

Use long, unique passwords for accounts and services that require them.

What About Changing the SSH Port?

Changing SSH from the default port 22 is often suggested as a brute-force defense.

It can reduce some automated scanning noise, but it should not be treated as a primary security control.

An attacker who discovers the new port can still attack the SSH service.

For that reason, this guide focuses on controls that directly improve authentication and access security:

• Strong authentication
• Restricted users
• Limited attempts
• Fail2ban
• Updates
• Monitoring

These controls remain useful regardless of which SSH port you use.

Conclusion

SSH does not need a complicated security configuration.

Start with the basics:

1. Keep OpenSSH and the operating system updated.
2. Disable direct root login.
3. Use SSH keys instead of passwords.
4. Restrict SSH access to required users.
5. Limit authentication attempts.
6. Add Fail2ban.
7. Test every configuration change.
8. Monitor SSH logs.

The most important part is to make changes carefully.

Before disabling password authentication or changing access rules, make sure your SSH key works and keep an existing session open while testing.

A few simple controls can make an internet-facing Linux server much harder to attack without making SSH difficult for legitimate administrators to use.

Recommended Read:

• How To Setup Multi-Factor Authentication For SSH In Linux
• How To Configure SSH Key-based Authentication In Linux
• Find If A User Is Using Password-based Or Key-based SSH Authentication
• How To Allow Or Deny SSH Access To A Particular User Or Group In Linux
• Disable SSH Password Authentication For Specific User Or Group