SSH Brute force attacks: Obvious way to secure your server
Learn about SSH brute force attacks and discover an effective way to secure your remote server from such threats by using SSH key authentication instead of login/password authentication.
Introduction
I want to cover a straightforward topic about using SSH key authentication to access your remote server as a preventive measure against unauthorized access in your environment. This article doesn't contain any big insights, and I'm not a cybersecurity professional, so this is not an article to cover the depths of securing remote servers (nor does it dig deep into discussing the insecure nature of SSH in general).
I'm just a software developer who operates a bunch of remote servers (mostly Ubuntu, VPS). These servers host many projects—test, live, commercial, educational, and demo—with numerous .env files. These are things you always want to keep private for yourself, your clients, and your colleagues.
Here are some first-hand measures that can at least reduce potential risks in case someone discovers your login/password and connects to your server through SSH.
And now, let's talk about SSH brute force attacks.
If you check the access logs of some of your servers that host indexed websites or are exposed to public domains through DNS, you might find numerous attempts to log in to your server from random IP addresses (often from unexpected geo-locations).
You're lucky that none of these attempts succeeded and were disconnected due to authentication failures (incorrect login/password combinations). However, statistically, one pair could match one day, and that's a problem. It's even easier if your login is named "root," isn't it?
So here you may find in your server access logs:
11:40:50.181
Dec 22 12:40:50 your-server sshd[4922]: Disconnected from authenticating user root xxx.xxx.xx.xxx port 41112 [preauth]
11:41:38.002
Dec 22 12:41:38 your-server sshd[5050]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=xxx.xxx.xx.xx user=root
11:41:39.751
Dec 22 12:41:39 your-server sshd[5050]: Failed password for root from xxx.xxx.xx.xx port 49826 ssh2
11:41:39.904
Dec 22 12:41:39 your-server sshd[5052]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=xxx.xxx.xx.xx user=root
11:41:39.940
Dec 22 12:41:39 your-server sshd[5050]: Received disconnect from xxx.xxx.xx.xx port 49826:11: Bye Bye [preauth]
11:41:39.940
Dec 22 12:41:39 your-server sshd[5050]: Disconnected from authenticating user root xxx.xxx.xx.xx port 49826 [preauth]
11:41:41.593
Dec 22 12:41:41 your-server sshd[5052]: Failed password for root from 179.95.180.141 port 53538 ssh2
11:41:41.787
Dec 22 12:41:41 your-server sshd[5052]: Received disconnect from xxx.xxx.xx.xx port 53538:11: Bye Bye [preauth]
11:41:41.787
Dec 22 12:41:41 your-server sshd[5052]: Disconnected from authenticating user root xxx.xxx.xx.xx port 53538 [preauth]
11:41:47.612
Dec 22 12:41:47 your-server sshd[5058]: Invalid user wyg from xxx.xxx.xx.xx port 52864
As you can see, there are different attempts from random IP addresses (imagine any random IP address instead of xxx.xxx.xx.xx) to connect to your server through SSH. This is how SSH brute force attacks look.
Understanding SSH Brute force attacks
A brute force attack is a method used by attackers to gain unauthorized access to accounts by systematically trying all possible password combinations. This approach can be incredibly effective if passwords are weak or not protected by additional security measures.
Many brute force attacks are automated using bots. Attackers deploy these bots across the internet to scan for servers with open SSH ports. Once a potential target is found, the bots use a list of commonly used usernames and passwords to attempt to log in. This method allows attackers to try thousands of combinations in a short period, increasing their chances of success.
Solution
To defend your server from these attacks, obvious solution is to replace SSH login/password authentication with SSH key authentication.
SSH keys provide a more secure alternative to password authentication, eliminating the chance for bots to quickly find the correct login/password combination.
Let’s go through step-by-step explanation how to make this twist.
Disclaimer: My local environment is Ubuntu (so keep in mind if you are using another operation system, which handle ssh key generation not in the same way as in Ubuntu, just find additionally how to do it with your setup).
Step 1: Generate SSH key-pair on your local
1. Open your terminal and input
ssh-keygen
2. Follow the prompts
You will be asked where to save the key. Press
Enter
to accept the default location (/home/user/.ssh/id_rsa
).Enter a passphrase for additional security, or press
Enter
to leave it empty.
You will receive as output something like this:
Your identification has been saved in /home/user/.ssh/id_rsa
Your public key has been saved in /home/user/.ssh/id_rsa.pub
The key fingerprint is:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (some real data here)
The key's randomart image is:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (some real data here)
Step 2: Copy generated public ssh key on your server
1. Input in terminal
ssh-copy-id your-server-username@your-server-ip
Replace
your-server-username
with your actual username on the server (which is configured to login on server through ssh)Replace
your-server-ip
with the server's IP address or host name
2. Enter Your Password
You will be prompted to enter your password for the server.
As output of this command you may receive something like this as output:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'your-server-username@your-server-ip'"
and check to make sure that only the key(s) you wanted were added.
And after these steps, you will be able to log in through SSH key authentication from your local machine to your remote server without needing to enter a password anymore.
3. Ensure that new SSH key authentication works correctly
Input in your console
ssh your-server-username@your-server-ip
Important
And only if you are able to log in to your server through this command, you may move forward to the second part of the process and disable login/password authentication in the server configuration (let’s explore this in step 4 below). It's important because if you will disable password authentication on your server, but your ssh-key authentication doesn’t work for some reasons, then you will loose access to your own server.
Careful with that axe, Eugene!
Step 3: Disable Password Authentication
1. Log in into your remote server
ssh your-server-username@your-server-ip
2. Open the SSH Configuration File
sudo nano /etc/ssh/sshd_config
3. Find and Edit PasswordAuthentication Directive
Change the line #PasswordAuthentication yes
to:
PasswordAuthentication no
Press Ctrl + X
, then Y
, and Enter
to save and exit.
4. Restart the SSH Service
sudo systemctl restart sshd
Step 4: Confirm changes
1. Once again try to log in to your remote server from local with ssh-key
ssh your-server-username@your-server-ip
You should successfully log in.
2. Try to login/password authentication
ssh your-server-username@your-server-ip -o PubkeyAuthentication=no
And you should see an error indicating that password authentication is not allowed which is our expected behavior.
Step 5: Backup your SSH private key
Ensure your private SSH key (home/user/.ssh/id_rsa
) is backed up securely (the path to id_rsa
is provided here as an example and may vary based on your setup). Keep it in a secure location, not only on your local computer, as it’s a crucial part of SSH key authentication. If you lose your key, you may have trouble logging into your remote server.
Conclusion
In this article, we’ve highlighted the problem of SSH brute force attacks - how they are done, how to identify if your server is struggling with them, and what the solution is.
The solution is obvious and straightforward - use SSH key authentication instead of login/password authentication.
You may find here a step-by-step guide on how to implement this solution.
Enjoy your enhanced security and don’t give bots a chance to find the back door into your servers.
Thank you for your attention!
Picture in preview credit:
Unsplash, FlyD