Log Dejargonizer

OpenSSH · Event Failed password

Failed password: an SSH login was rejected

Someone tried to sign in over SSH with the wrong password. On any server reachable from the internet these arrive constantly — automated scanning, not a targeted attack. What matters is whether one ever succeeded.

Also written as Failed password forsshd failed passwordssh failed password rootFailed password for invalid user

What it means for you

On a personal computer

If you have opened SSH to the internet — for a home server, a Raspberry Pi, or a NAS — you will see thousands of these. It is automated scanning that finds every public address within hours. The real fix is to turn off password authentication entirely and use keys.

For an analyst

The message distinguishes an existing account from a non-existent one by inserting 'invalid user', which is the equivalent of the Windows sub-status distinction. Rate-limiting tools reduce log volume but do not address the underlying exposure. The question worth alerting on is a success from a source that produced failures, not the failures themselves.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
Aug 28 09:41:17 web-01 sshd[24817]: Failed password for invalid user admin from 198.51.100.77 port 49820 ssh2
Aug 28 09:41:19 web-01 sshd[24817]: Failed password for root from 198.51.100.77 port 49822 ssh2
Aug 28 09:41:21 web-01 sshd[24819]: Failed password for jbrooks from 198.51.100.77 port 49824 ssh2

The fields that decide it

Everything else in the log line is context.

user
The account name that was tried.
  • rootThe most-targeted account by a wide margin. Should not accept password authentication at all.
  • admin, test, oracle, ubuntu, piStandard entries in scanning wordlists. Their presence tells you nothing except that you are exposed.
  • A real account name from your organisationMore concerning than a generic one — it suggests the attacker knows something.
invalid user
Present when the account does not exist. Its absence means the username was real, which is the more interesting case.
  • PresentThe account does not exist. Untargeted scanning.
  • AbsentThe account exists and only the password was wrong.
source address
Where the attempt came from.
port
The source port, useful for correlating with connection-level logs.
ssh2
The protocol version, present in most modern messages.

Ordinary reasons this happens

Most of the time it is one of these.

  • A user mistyping a password.
  • An automation script or backup job with an outdated credential retrying on a schedule.
  • A saved connection in an SSH client still offering an old password.
  • A monitoring check configured with credentials that changed.
  • Internet background scanning against any public address, which accounts for nearly all of the volume.

When it is not ordinary

Automated credential guessing against exposed SSH.

What gives it awayHigh volume from one source across common usernames. This is the default state of any internet-facing SSH service.

ATT&CK T1110.001

Password spraying against known accounts.

What gives it awayAttempts against real usernames without the 'invalid user' marker, at low volume per account to avoid rate limits.

ATT&CK T1110.003

A targeted attempt using known account names.

What gives it awayFailures against real organisational usernames rather than generic wordlist entries.

ATT&CK T1110

A successful compromise following the failures.

What gives it awayAn Accepted password entry from a source address that produced failures shortly before. This is the sequence that actually matters.

ATT&CK T1078

What to do next

  1. Check whether 'invalid user' is present. A real username that only failed on the password is a different situation.
  2. Look for an Accepted entry from the same source address afterwards. That is the question worth answering.
  3. Count distinct usernames per source. Many names from one address is untargeted scanning.
  4. Check whether the source is internal. An internal source is a compromised host or a stale credential, not internet noise.
  5. If the volume is from the internet and password authentication is enabled, disable it — that is the finding.
  6. For internal sources, find the script or saved credential rather than resetting the account again.

Queries to run

grep Top sources by failure count. On Red Hat derivatives use /var/log/secure instead. 
grep 'Failed password' /var/log/auth.log | grep -oP 'from \K[\d.]+' | sort | uniq -c | sort -rn | head -20
grep Addresses that both failed and succeeded. This short list is the one that matters. 
grep 'Accepted' /var/log/auth.log | grep -oP 'from \K[\d.]+' | sort -u > /tmp/ok.txt; grep 'Failed password' /var/log/auth.log | grep -oP 'from \K[\d.]+' | sort -u | grep -Ff /tmp/ok.txt
grep Failure count over the last day on a systemd host, where auth.log may not exist. 
journalctl -u ssh -u sshd --since '24 hours ago' | grep -c 'Failed password'
elastic 
event.dataset:"system.auth" and process.name:"sshd" and system.auth.ssh.event:"Failed" | stats count by source.ip, user.name
splunk One source trying many usernames — the shape of untargeted scanning. 
index=linux sourcetype=linux_secure "Failed password" | stats count dc(user) as users by src_ip | where users > 5 | sort -count

Common questions

I get thousands of SSH failed password attempts. Am I being attacked?

You are being scanned, which is not the same thing. Every publicly reachable address receives continuous automated login attempts within hours of coming online, and the volume says nothing about whether anyone is targeting you specifically. The right response is to remove password authentication rather than to chase the sources.

How do I stop SSH brute force attempts?

Disable password authentication entirely and use key-based authentication — set `PasswordAuthentication no` in sshd_config. That makes the guessing pointless regardless of volume. Rate-limiting tools like fail2ban reduce the log noise and are worth running, but they address the symptom rather than the exposure.

What is the difference between 'Failed password for root' and 'Failed password for invalid user root'?

The 'invalid user' wording means no such account exists on the system. Without it, the account is real and only the password was wrong. That distinction matters: failures against real usernames suggest the attacker has some knowledge of your environment, while failures against non-existent ones are generic scanning.

How do I check whether anyone actually got in?

Search the same log for 'Accepted' entries, and cross-reference the source addresses against those that produced failures. An address that failed repeatedly and then succeeded is the case to investigate. `last` and `lastb` also give you a quick summary of successful and failed logins respectively.

Read next

Mentioned by

Vendor documentation

Last reviewed 28 August 2026