Log Dejargonizer

OpenSSH · Event Invalid user

Invalid user: an SSH login for an account that does not exist

Someone tried to sign in with a username the system has never heard of. It is the clearest possible signal of untargeted scanning, because the usernames come straight from public wordlists rather than from anything about your organisation.

Also written as Invalid usersshd invalid userssh invalid user log

What it means for you

On a personal computer

Someone tried to log in with a username that does not exist on your machine. Automated scanning does this constantly to anything reachable from the internet.

For an analyst

The usernames themselves are the interesting part. Generic wordlist entries mean untargeted scanning. Real employee names, or accounts specific to your applications, mean someone has done reconnaissance — and that is a materially different situation.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
Aug 28 09:41:15 web-01 sshd[24817]: Invalid user admin from 198.51.100.77 port 49820
Aug 28 09:41:15 web-01 sshd[24817]: pam_unix(sshd:auth): check pass; user unknown
Aug 28 09:41:17 web-01 sshd[24817]: Failed password for invalid user admin from 198.51.100.77 port 49820 ssh2

The fields that decide it

Everything else in the log line is context.

user
The account name that was tried. What kind of name it is matters more than the name itself.
  • admin, test, oracle, ubuntu, pi, guestStandard wordlist entries. Untargeted.
  • A real employee name or an application accountSuggests reconnaissance. This is the case worth investigating.
source address
Where the attempt came from.
port
The source port, useful for correlating with connection records.

Ordinary reasons this happens

Most of the time it is one of these.

  • Internet background scanning, which accounts for essentially all of it on a public server.
  • A user attempting to connect to the wrong host.
  • An automation script pointed at the wrong server.
  • A decommissioned account still configured somewhere.

When it is not ordinary

Automated scanning for default accounts.

What gives it awayGeneric usernames from many different source addresses. Continuous and untargeted.

ATT&CK T1110.001

Reconnaissance using known organisational names.

What gives it awayUsernames matching real employees or your naming convention, which cannot come from a public wordlist.

ATT&CK T1589.002

Probing for application-specific accounts.

What gives it awayUsernames matching software you actually run, suggesting the attacker knows what is on the host.

ATT&CK T1087

What to do next

  1. Look at what kind of usernames are being tried. Generic means scanning; specific means reconnaissance.
  2. Count distinct usernames per source address.
  3. Check whether any attempted username is close to a real account on the system.
  4. Check whether the source is internal — an internal source is a misconfiguration or a compromised host.
  5. If the volume is a problem, rate-limit rather than trying to block individual sources.

Queries to run

grep Which usernames are being tried. Read this list — generic entries mean scanning, and anything specific to your organisation does not. 
grep 'Invalid user' /var/log/auth.log | grep -oP 'Invalid user \K\S+' | sort | uniq -c | sort -rn | head -30
grep 
grep 'Invalid user' /var/log/auth.log | grep -oP 'from \K[\d.]+' | sort | uniq -c | sort -rn | head -20
splunk 
index=linux sourcetype=linux_secure "Invalid user" | stats dc(user) as users count by src_ip | sort -count

Common questions

What does 'Invalid user' mean in auth.log?

Someone tried to log in with a username that does not exist on the system. On any internet-facing server this happens continuously as automated scanners work through lists of common account names — it means you are reachable, not that you are targeted.

Should I block IPs that trigger invalid user attempts?

Blocking individual addresses achieves very little, because scanning comes from a constantly changing pool. Rate-limiting with something like fail2ban keeps the log volume down, but the durable fix is to disable password authentication so the guessing cannot succeed regardless of who is doing it.

When should I actually worry about invalid user attempts?

When the usernames stop being generic. 'admin' and 'test' come from public wordlists. Real employee names, or accounts specific to the software you run, cannot — those indicate someone has looked at your organisation, which is a different problem from background scanning.

Read next

Mentioned by

Vendor documentation

Last reviewed 28 August 2026