Post cover image

September 4, 2026

127,002 SSH Failure Events Hit My Linux Server in 30 Days. Here’s What They Targeted

The logs weren’t showing one attacker. They were showing constant automated probing for root, admin, cloud, crypto, deployment, and…

By Faruk Ahmed

3 min read

The logs weren't showing one attacker. They were showing constant automated probing for root, admin, cloud, crypto, deployment, and application accounts.

I recently went back through 30 days of SSH logs on one of my Internet-facing Linux servers.

I wasn't looking for anything complicated.

I wanted to answer a simple question:

What is actually hitting SSH when you leave a Linux server exposed to the Internet?

I started with this:

sudo journalctl -u ssh --since "30 days ago" --no-pager | \
grep -E "Failed password|Invalid user" | wc -l

The result:

127002

That number needs some context.

An invalid login can generate more than one SSH log entry. For example:

Invalid user school from <IP>
Failed password for invalid user school from <IP>

So I would not call those 127,002 unique attacks.

They are 127,002 SSH failure-related log events matching those two conditions.

That distinction matters.

But what interested me more than the total was what the systems were trying to log in as.

Root Was Still a Huge Target

I checked direct failed password attempts against root:

sudo journalctl -u ssh --since "30 days ago" --no-pager | \
grep "Failed password for root" | wc -l

The result:

32266

32,266 failed password events against root in 30 days.

That is one account.

Nothing sophisticated was required.

The SSH service was reachable, so automated systems kept testing it.

Recent examples looked like this:

Failed password for root from <IP> port 37826 ssh2
Failed password for root from <IP> port 44300 ssh2
Failed password for root from <IP> port 47684 ssh2
Failed password for root from <IP> port 59166 ssh2

Different source addresses.

Same target.

root.

This is why I never look at a few failed SSH attempts and assume they represent a person manually trying passwords.

On an Internet-facing server, much of this traffic is automated and continuous.

The Usernames Were More Interesting

Root wasn't the only thing being tested.

Among the usernames appearing in the logs were names like:

admin
ubuntu
wallet
crypto
bitcoin
node
deploy
pm2
blockchain
exchange
server
cloud
panel
solana
centos
docker

And in only a small recent sample I saw:

school
usuario1
info
scanuser
kemp
ben
esmtp
token
node
monitor
printer
blockchain

That tells me something useful.

The probing isn't limited to:

root
admin
test
user

There are attempts aimed at accounts that might exist on:

  • Ubuntu systems
  • deployment servers
  • Node.js environments
  • Docker hosts
  • cloud infrastructure
  • control panels
  • monitoring systems
  • cryptocurrency infrastructure

An attacker doesn't need to know whether those accounts exist.

At scale, trying them is cheap.

One Source Generated More Than 1,000 Matching Events

I also looked at the source addresses producing the most matching SSH failure events.

The top of the list included:

1373  193.24.211.204
605   101.99.14.34
588   209.97.183.43
448   143.198.117.123
408   159.65.94.135
402   159.65.95.5
398   45.55.236.117
397   144.126.225.192

Again, I treat these as log-event counts, not confirmed unique intrusion attempts.

But the pattern is still useful.

Some sources touch the server once or twice.

Others keep coming back.

That's one of the reasons I care more about behavior over time than a single failed login.

What I Actually Look For

Thousands of failed passwords by themselves don't tell me that a server was compromised.

What gets my attention is a change in the pattern.

For example:

A username that suddenly starts being targeted heavily

Repeated attempts against a real local account

A source that fails repeatedly and later gets an accepted login

Successful authentication from an address I don't recognize

Authentication at a time that doesn't match normal administration

A new SSH key or account appearing around the same time

That is when failed-login data becomes much more useful.

The question isn't simply:

Are people attacking SSH?

If SSH is exposed to the Internet, the answer is usually yes.

The better question is:

Did any of that activity turn into access?

The Command I Use to Check Successful Logins

After reviewing failures, I also check accepted authentication:

sudo journalctl -u ssh --since "30 days ago" --no-pager | \
grep "Accepted "

On this server, the successful entries I reviewed corresponded to my expected administrative access.

That's what I wanted to see.

But I never assume that before checking.

A failed login tells me someone tried.

An accepted login tells me someone got in.

Those are very different events.

What This Changed for Me

Seeing thousands of SSH failures isn't surprising anymore.

What still matters is the context around them.

I want to know:

  • which accounts are being targeted
  • which sources keep returning
  • whether real accounts are involved
  • whether a failure is followed by success
  • whether authentication behavior changed

That's much more useful than simply watching the failure counter increase.

And there is another thing I want to dig into next:

Which usernames were targeted most often, and what does that tell us about what automated SSH scanners are looking for?

I'll break that down separately rather than burying it inside this article.

Want to Check Your Own SSH Exposure?

If you manage a Linux server exposed to the Internet, I created a free SSH Hardening Checklist covering the controls I check when reviewing SSH security.

Free download: Get the SSH Hardening Checklist

I also built SSH-IDS, a real-time SSH intrusion detection tool for Linux, for administrators who want to monitor SSH activity instead of manually digging through authentication logs.

SSH-IDS: See SSH-IDS

I'm continuing to analyze this 30-day SSH dataset. Next, I'm looking deeper at which usernames were targeted most often and what those names tell us about automated SSH scanning.

Follow me on Medium if you want to see that analysis. Next I'm digging deeper into the usernames these systems were trying.

Follow me on social media also:

🔗 LinkedIn: https://www.linkedin.com/in/bornaly/ ✍️ Medium: https://medium.com/@bornaly/subscribe 💬 Discord: https://discord.gg/FkjR2WFs 🐦 X (Twitter): https://x.com/cyberwebpen 📘 Facebook: https://www.facebook.com/nextgenthreat