How to Prevent SSH Brute Force Login Attacks

Originally published: April 20, 2023 by Rianna MacLeod

An SSH brute force attack is an automated login-guessing run against your server’s remote access service, and it’s one of the most common ways a server ends up compromised.

Three defenses do most of the work:

Switch to SSH key authentication and turn password logins off
Put an automatic IP-blocking tool like Fail2Ban or DenyHosts in front of the service
Require two-factor authentication anywhere a password still works.

Below we walk through those three, plus three more layers, one step at a time.

Jump to a solution:

What is an SSH brute force attack?

A Secure Shell (SSH) brute force attack is a common form of attack that targets remote services, particularly unix-based servers running SSH services for secure remote connections. These attacks often involve automated tools and bots to continuously attempt common password and username combinations until they successfully gain access to a server. Excessive numbers of failed log-ins can indicate a brute-force attack on your SSH server.

Why do attackers brute force SSH?

An attacker may be motivated to brute force SSH for a number of reasons. Brute force attacks serve as a method to discover the correct username and password combination or a hashed token — and if successful, can allow an attacker to gain unauthorized access to valuable financial information and files, disrupt services, distribute malware to other systems, or even hijack the compromised system for their own purposes. This trial-and-error approach to hacking is based on guessing credentials, file paths, or URLs, either through a logical process or by attempting all possible key combinations, often starting with the most commonly used passwords.

Bad actors often utilize hack tools to automate and expedite the brute force attack process. They may distribute the attack across multiple source locations or use malware to target protected internal accounts. Widely known tools, such as Hydra, Chaos, CrackMapExec, and PoshC2, are equipped with brute force functionalities that perform rapid attacks against different protocols.

How can you tell if your server is under an SSH brute force attack?

The signal is usually sitting in your logs. A burst of failed password entries — sometimes from a single IP, often from dozens rotating through the same list of usernames — is the clearest indicator. On Debian and Ubuntu systems those entries land in /var/log/auth.log, while RHEL-family systems record them in /var/log/secure.

A quick look at recent failures:

$ sudo grep 'Failed password' /var/log/auth.log | tail -50

You may also notice unexplained CPU load during those bursts, since every attempt requires a fresh round of SSH protocol negotiation. That’s worth paying attention to: a sustained attack can degrade performance even when it never succeeds.

And if the failures suddenly stop and a session opens from an unfamiliar address, don’t read that as a lull. Treat it as a possible compromise and check for new user accounts, unexpected entries in authorized_keys, and recently modified files.

How to protect your server from SSH brute force attacks

SSH brute force protection works in layers, and no single change below carries the whole load. Each one is covered in detail below, with the configuration changes involved.

The six steps are ordered roughly by how much they help. Start at the top, and add as many as your environment allows.

1. Switch to SSH key authentication

Using the default username/password authentication for SSH can make your server more vulnerable to brute-force attacks. You can enhance security by implementing key-based SSH authentication, which uses public and private SSH key pairs. Keep the private key on the client’s computer and copy the public key to the server. SSH keys are virtually impossible to guess or compromise via brute-force.

During SSH key authentication, your server verifies if the client’s computer has a correct private key. If authentication is successful, a shell session is created and an SSH connection is established between the client and the host.

To disable password authentication, edit your SSH configuration file:

$ sudo vim /etc/ssh/sshd_config

Set the PasswordAuthentication parameter to no:

PasswordAuthentication no

Save the file and reload SSH to apply the changes (on some distributions the service is named sshd rather than ssh):

$ sudo systemctl reload ssh

This can also be configured during the initial creation of your virtual private server, depending on the hosting provider you are using.

2. Limit authentication attempts

To further protect SSH against brute force attacks, you can limit the number of authentication attempts allowed per connection. This can be accomplished by adjusting the MaxAuthTries directive in your sshd_config file.

An authentication attempt refers to any enabled authentication method in the sshd configuration, such as offering a SSH key, attempting Kerberos/GSSAPI authentication, or typing a password into the authentication prompt. Each authentication attempt counts as one attempt towards accessing the server.

A recommended starting point is setting MaxAuthTries to 3 to balance security and user experience. Keep in mind that this limit applies per connection, not per source address — capping attempts per IP over time is what the tools in the next step handle.

Important caveat:

If your main concern is protecting against password-guessing attacks from worms and bots on other compromised systems, then reducing the MaxAuthTries setting may not be the best approach. Bots will continue to try to guess passwords endlessly, placing a strain on your CPU as SSH protocol negotiations are required for each attempt. Your priority should instead be to prevent the bot from succeeding in its attack and to keep it occupied for as long as possible on the existing connection. Allowing multiple authentication attempts over one connection and responding extremely slowly might achieve this.

It’s also worth noting that sshd will still request a password from the client even if password authentication is disabled. This is because the prompt is fake, and the client will always be rejected regardless of the password entered. However, the client won’t know this for certain.

If you do allow too many authentication attempts over one connection, the bot may eventually terminate the connection from its side. This is because some bot programmers implement a timeout to limit the effectiveness of “tar-pit defenses.”

3. Implement brute force protection with third party tools

A number of tools are available for administrators to protect SSH against brute force attacks:

DenyHosts is a Python-based security tool designed to protect SSH servers from brute-force attacks. It works by monitoring the authentication log for invalid login attempts and blocking the IP addresses from which they originate.
Fail2Ban uses jails configuration files that consist of a filter and a set of actions to scan your server logs for suspicious activity, such as failed login attempts. Once the filter detects something concerning, it can trigger one or more actions. These actions may include blocking the suspicious IP address for a specific period or sending an email notification to the server admin.
Pam_abl provides a blacklist of hosts and users that have repeatedly failed authentication attempts. This tool can be downloaded and installed to block these hosts and users from accessing the server.
SSHBan receives data directly from the loggers instead of scanning system logs. This tool can also be used to monitor and block IP addresses that have multiple failed login attempts.
OSSECHIDS is a platform used to monitor and control your systems. It includes useful features such as file integrity monitoring and attack detection which can come in handy for detecting indicators of compromise.

Keep in mind that not all third party tools are created equal. Do your own due diligence and thoroughly read documentation for tools prior to installing them in your environment.

4. Restrict server access with TCP wrappers

To protect your servers from brute force attacks, you can use TCP wrappers to limit access to specific hosts. TCP wrappers allow you to restrict access to TCP services based on IP address or hostname. To accomplish this, you can use the hosts.allow and hosts.deny files.

The first step is to deny all hosts in the /etc/hosts.deny file. Add the following lines:

# hosts.deny

ALL: ALL

This will block all hosts from accessing any TCP service on your server.

Next, you can specify the hosts and domains that are allowed to connect to SSH in the /etc/hosts.allow file.

# hosts.allow

sshd: server1.example server2.example
sshd: 123.456.78.910

With this configuration, only the specified hosts in the hosts.allow file will be able to connect to SSH on your server, effectively protecting it from unauthorized access. Allowlisting an IP in this manner is an effective security measure to protect your server. It reduces the attack surface, minimizes unauthorized access, and can even help organizations meet regulatory requirements.

5. Implement two-factor authentication (2FA)

Incorporating two-factor authentication (2FA) is a straightforward and efficient way to enhance security and protect SSH against brute-force attacks. The Google Authenticator PAM module is a popular choice for this use case.

To set up Google Authenticator:

Build and install the PAM module
Configure SSH and set up a user for the Authenticator; for the highest security, ensure that both password and one-time passcode (OTP) are requested
Restart the sshd service
Enable ChallengeResponseAuthentication in the sshd_config file and run the google_authenticator command

After completing these steps, you’ll need to provide both a password and a one-time passcode from Google Authenticator when logging into SSH.

6. Use a non-standard port for SSH

Changing the port won’t stop a determined attacker. A scan with a tool like nmap finds SSH wherever you put it, but it does cut most opportunistic bot traffic out of your logs, which makes the attacks that matter far easier to spot. Treat it as noise reduction rather than protection, and never as a substitute for steps 1 through 5.

To force SSH to run on a non-standard port:

Open /etc/ssh/sshd_config in a text editor.
Browse to the line containing # Port 22.
Uncomment and define this as a different port. For example: Port 2212.
Save and exit the file.

If you are currently connected to the SSH server on port 22, your connection will drop. You’ll need to reconnect using the new port you defined in your sshd_config file.

Closing thoughts

Implementing a multifaceted approach to SSH security can help you significantly reduce the risk of brute force attacks on your server. Adopting key-based authentication, limiting authentication attempts, using third-party tools, restricting access through TCP wrappers, and implementing two-factor authentication will collectively strengthen your server’s defenses and protect sensitive data.

None of it is set-and-forget, though. Review your authentication logs periodically, keep OpenSSH patched, and revisit which IP addresses and which keys still genuinely need access. Stale credentials tend to outlive the people who used them.

Brute force attacks can also occur through various interfaces like FTP and admin panels (such as Joomla, Drupal, WordPress, etc.). So if you’re looking for a simple and effective solution to protect your website from brute force attacks, check out our web application firewall service. It makes it super easy to restrict access, protect wp-admin login pages, and harden your WordPress environment.

Frequently asked questions

What is the most common SSH brute force tool?

Hydra is the most widely recognized, and credential-guessing is also built into toolkits like Chaos, CrackMapExec, and PoshC2. Attackers often spread the same attack across many source IPs, so the specific tool matters far less than whether your server still accepts password logins at all.

How many failed login attempts trigger a lockout?

That depends entirely on how you’ve configured things. OpenSSH’s MaxAuthTries caps attempts within a single connection, and we suggest starting at 3. Tools such as Fail2Ban and DenyHosts count failures across connections and ban the source IP once it crosses a threshold you set yourself.

Does changing the SSH port really stop brute force attacks?

Not on its own. A scan with a tool like nmap will find SSH wherever you move it, so treat a non-standard port as noise reduction rather than protection. It does thin out opportunistic bot traffic in your logs, but key-based authentication, IP restrictions, and 2FA are what actually block access.

Can I detect if my server is under SSH attack?

Usually, yes. Repeated failed password entries in your authentication log, from one IP or from many rotating through the same usernames, are the clearest sign, and unexplained CPU load during those bursts is another. A monitoring platform like OSSEC HIDS can alert you to both the failures and any file changes that follow.

What should I do first to stop SSH brute force login attempts?

Move to key-based authentication and set PasswordAuthentication to no. Once there’s no password to guess, most automated attacks have nothing left to work with. After that, add an IP-blocking tool and two-factor authentication for any account that can still authenticate interactively. Our guide to SSH security best practices covers the wider setup.