How SSH Attacks on Linux Servers Work, and How to Shut the Door

by Souy Soeng /November 05, 2026

Diagram of an SSH attack on a Linux server: bot scans port 22, guesses passwords, then gains a shell

SSH attacks on Linux servers are automated attempts to log in to a machine through its Secure Shell service, usually by scanning for an open port, guessing passwords, or using a stolen key. Put a Linux server on the internet, and bots will start trying to log in within minutes. They don't know who you are, and they don't care.

This guide follows one attack from the first scan to full control of a server. Then it turns each step into a defence you can apply today: key-based logins, no root login, regular patching and watching your logs. None of it needs extra software. Most of it comes down to settings you already have.

In short

Every public SSH server gets automated login attempts, often within minutes of going live.
Bots scan for port 22, read the version banner, then guess or replay passwords.
Stolen keys, open root login and old OpenSSH versions let attackers skip guessing entirely.
Once inside, attackers plant backdoor keys, run malware and move to other systems.
Keys on, root off, patch regularly and watch every login: that blocks most attacks.

Many people launch a fresh server, check the logs and are surprised. There are no users yet, but the auth log is already full of failed logins from strangers. This is not a targeted attack. It is simply the normal state of the internet. Nobody has to know your server exists. It only needs a public IP address and an open SSH port to start getting attention.

Automated bots don't sleep and don't pick their targets carefully. They try every server they can reach, and that includes yours. The constant attempts matter because of what sits behind the login. If a single attempt succeeds, the attacker isn't inside one app. They're sitting at the command line of your server.

Constant attempts: bots probe every public SSH server, often within minutes.
Real stakes: one successful login can hand over the whole machine.

What is SSH, and why do attackers target it?

SSH, short for Secure Shell, is the encrypted protocol admins use to run Linux servers from anywhere. Every session follows the same short conversation. The client connects to port 22. The server replies with its version and host key. The two sides do a key exchange, the channel becomes encrypted, and then comes the login, with a key or a password. If that works, you get a shell prompt.

Because the tunnel is encrypted, passwords and commands can't be read on the network. That is why attackers rarely go after the encryption itself. They target the login step instead. And the login is worth a lot. Installing packages, editing configs and restarting services all happen through this one door.

Unlike a website form, a successful SSH login doesn't give you one feature. It gives you the whole machine. Think of it as stealing the building manager's master key instead of the key to a single apartment. Whatever the account can do, the attacker can now do. If it's root, or a user with sudo, there's almost nothing they can't change.

There is a second reason attackers like SSH: quiet access. A login with valid credentials looks just like an admin signing in. Unless someone watches closely, nobody notices anything at all.

Run commands and read files
Reach databases and the internal network
Borrow your CPU power for their own jobs

How do bots find SSH servers to attack?

An attack doesn't start with a password guess. It starts with a search for anything that answers on the SSH port. This scanning runs across the whole internet continuously, so being found isn't a question of if, but when. A scanner can run a tool like nmap across a whole IP range, looking only at port 22, and quickly list every host with SSH open.

Next, it simply connects, for example with netcat, and the server announces itself. This banner shows the protocol version, the OpenSSH version and often the operating system. That detail matters. If the banner shows an outdated OpenSSH release, the bot can flag the server for a known exploit instead of a slow password guess.

A common question is whether moving SSH to another port helps. It cuts down the noise in your logs, but it isn't real protection, because scanners check other ports too. Treat it as tidying, not security.

Port 22 sweeps are automated, cheap and aimed at every reachable address.
The version banner can point attackers to known vulnerabilities.

nmap -p 22 --open 203.0.113.0/24
nc 203.0.113.10 22

Brute force vs credential stuffing: how passwords fall

Once a bot has a list of open SSH servers, the next step is finding a working login. The cheapest way is to try credentials over and over. There are two flavours. Brute force cycles through common usernames and passwords such as root, admin, test and 123456, endlessly. It is slow, but it never stops.

Credential stuffing is smarter. It replays real usernames and passwords leaked in earlier breaches of other services, betting that someone reused the same password on their server. It needs fewer tries and gets more hits. Both methods are fully automated, and both rely on the same human habit: weak or reused passwords.

You can see this happening from your side. Tail the auth log and you'll find lines about invalid users like admin and test, plus failed passwords for root, arriving from different addresses. Why does it work? Simple arithmetic. The bot can afford countless failures because it only needs one success, and without rate limiting nothing slows it down.

sudo tail /var/log/auth.log

How attackers get in without guessing a password

Guessing isn't the only way in. Some servers hand attackers a shortcut. Each of these is a weakness in how the server or its keys are managed, not in a password. The first is a stolen private key, copied from a compromised laptop, a backup or a leaked code repository. It simply logs in, and because it is a real key, the login looks perfectly legitimate.

The second is an exposed root login. Every Linux server has a root account, so the attacker already knows the username and only the password is unknown. That halves their work, and if it succeeds there is no limit on what they can do. The third is unpatched SSH software, which keeps published vulnerabilities alive on your server. Fixes exist, but they only protect you once you install them.

Protect private keys with a passphrase.
Remove old keys from servers when people leave or laptops are retired.
Don't allow direct root login over SSH.
Keep OpenSSH updated so known bugs get closed.

What happens after an SSH break-in?

Getting in is only step one. Attackers usually don't smash things. They make sure they can come back, put the server to work, and look for the next target. First, they often plant a backdoor key in an authorized_keys file, so their access survives even if you change the password. Then they install a cryptominer or other malware.

After that, they may use the compromised server to reach systems that were never exposed to the internet, such as an internal database. Internal systems often trust each other, so one weak SSH server can become a stepping stone to your most important data. This is also why changing passwords after an incident isn't enough. Review every authorized_keys file too.

A common real-world pattern looks like this. Someone launches a cloud VM and thinks, "quick test server, a password is fine." It goes live with port 22 open and root allowed. A scanner bot finds it and starts guessing: root, admin, test. Eventually one works, and the log shows an accepted password for root, followed by a new key and a running cryptominer. Nothing about it was sophisticated, which is exactly why it catches so many people.

Common SSH security mistakes to avoid

Most break-ins trace back to the same few mistakes, and every one is easy to fix. None of them are exotic. They are usually defaults nobody went back to review, often on a server someone thought of as "just a test." A default config, never reviewed, is exactly what these bots are built to find.

Password-only logins can be guessed or stuffed with leaked credentials, so switch to SSH keys and then turn password logins off. Allowing root login hands attackers a username they already know, so log in as a normal user and use sudo when you need more. With no rate limiting, bots get unlimited free guesses. And ignored auth logs hide attacks that were in plain sight.

Password-only logins: use keys instead.
Root login allowed: a known username with total power.
No rate limiting: tools like fail2ban block repeat offenders.
Ignored auth logs: check them or send them to monitoring.

How to harden SSH on a Linux server

A few lines of configuration, plus a couple of habits, block most automated attacks outright. Before you start, confirm that logging in with your key works, or you may lock yourself out. Then open the sshd config file and turn PubkeyAuthentication on, set PasswordAuthentication to no so guessing becomes pointless, and set PermitRootLogin to no.

Reload the ssh service, but keep your current session open while you test a new login in a second window. If something is wrong, you still have a way back in to fix it. The config change itself takes only minutes.

The habits matter as much as the settings. Patch regularly so known OpenSSH bugs get closed; automatic security updates handle most of this for you. Rate limit failed attempts with fail2ban or firewall rules, so addresses that keep failing simply get blocked. And watch every login, especially the successful ones. An accepted login from an address you don't recognise, or a new key you didn't add, is the moment to act.

Keys only, passwords off
No root login
Patch OpenSSH and the OS on a schedule
Rate limit and monitor logins

# /etc/ssh/sshd_config
PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin no
$ sudo systemctl reload ssh

Key takeaways

Bots scan the internet for open port 22 and read the SSH version banner.
Weak and reused passwords fall to brute force and credential stuffing.
Stolen keys, open root login and old software let attackers skip guessing.
Once inside, attackers plant backdoor keys, run malware and pivot inward.
The fix: keys on, root off, patch regularly, and watch every login.

Frequently asked questions

Is it normal to see failed SSH logins on a brand-new server?

Yes. Any server with a public IP address and an open SSH port attracts automated login attempts, often within minutes. It isn't a sign you've been targeted personally, but it is a reminder to harden the login.

Does changing the SSH port stop attacks?

It reduces log noise, but it isn't real protection, because scanners check other ports too. Key-only logins, disabling root and rate limiting do far more.

What's the difference between brute force and credential stuffing?

Brute force tries common usernames and passwords like root, admin and 123456 over and over. Credential stuffing replays real logins leaked in other breaches, betting that the password was reused on your server.

Why should I disable root login over SSH?

Every Linux server has a root account, so attackers already know the username and only need the password. If they succeed, they have unlimited control. Log in as a normal user and use sudo instead.

Is changing my password enough after a suspected SSH break-in?

No. Attackers often add their own key to an authorized_keys file, which keeps working after a password change. Review every authorized_keys file and check the logs for unexpected successful logins.

How do I avoid locking myself out when disabling SSH passwords?

Confirm that your key login works before you set PasswordAuthentication to no. After reloading the ssh service, keep your current session open and test a new login in a separate window.

Watch the full video on YouTube →

Tag

Ad