sshd "Invalid user … from … port …": What the Line Means

Oct 18 03:51:11 web1 sshd-session[48211]: Invalid user admin from 203.0.113.7 port 54321
Oct 18 03:51:12 web1 sshd-session[48213]: Invalid user postgres from 203.0.113.7 port 54337
Oct 18 04:02:44 web1 sshd-session[48502]: Invalid user solana from 198.51.100.22 port 40118

What it means

sshd writes this line during user authentication when the name the client asked to log in as is not a valid account on this host. Nothing was checked against a real user: there is no stored password hash and no authorized_keys file behind the name, so the attempt cannot succeed.

To avoid leaking which names exist, sshd does not drop the connection at this point. It carries on the authentication dialogue against a dummy record, so a password attempt against an invalid name takes roughly as long as one against a real account. That is why an Invalid user line is normally followed by one or more Failed password for invalid user … lines from the same PID before the client gives up or is disconnected.

The fields in the message are the requested user name, the client address and the client’s source port. The source port is the detail most people skip and the one that lets you match the line to a firewall, NAT or flow record for the same connection. An account that exists but is refused — not listed in AllowUsers, matched by DenyUsers, locked, or without a valid shell — does not produce this line. sshd logs User … from … not allowed because … instead, and the failures that follow still read Failed password for invalid user …, because sshd treats the refused account as invalid for the rest of the connection. So “invalid user” in a Failed line does not prove the name is missing; an Invalid user line does.

Is it an attack?

Almost always, in the sense that it is unsolicited: hosts with port 22 open to the internet receive a constant stream of these from scanners and botnets working through name lists. On its own one line is background radiation. The shape around it is what matters.

Pattern	Reading
One address, dozens of different names in minutes	Account enumeration / dictionary brute force
Many addresses, the same short name list (root, admin, test, ubuntu)	Distributed botnet sweep, untargeted
Names matching your products or staff (deploy, postgres, solana)	The host was fingerprinted; the list is tailored
An internal address, one name, on a regular schedule	A cron job, backup agent or CI runner using an account that no longer exists
Invalid user from an address, then an Accepted line from the same address	Investigate immediately — the attacker eventually used a name that works

Note that root never produces this line: root is a valid account, so failures for it appear differently. A real user name in a failure message without the words “invalid user” is a stronger signal than a hundred invalid ones.

How to investigate

Count sources and names before you judge anything. On Debian/Ubuntu the unit is ssh and the file is /var/log/auth.log; on RHEL/Fedora use -u sshd and /var/log/secure.

# Last 24 hours, straight from the journal (Debian/Ubuntu)
sudo journalctl -u ssh --since "24 hours ago" | grep "Invalid user"

# Busiest source addresses
sudo grep -oP 'Invalid user \S+ from \K\S+' /var/log/auth.log \
  | sort | uniq -c | sort -rn | head -20

# Most-tried user names
sudo grep -oP 'Invalid user \K\S+' /var/log/auth.log \
  | sort | uniq -c | sort -rn | head -20

# Failures against names that DO exist — these matter more
sudo grep "Failed password for" /var/log/auth.log | grep -v "invalid user"

# Did anything from those addresses ever get in?
sudo grep -E "Accepted (password|publickey)" /var/log/auth.log | tail -50

Compare the name list against /etc/passwd. If an internal host is the source, find the job: the user name in the line is usually the account a script was told to use. For bulk analysis of an exported auth.log, the free browser log analyzer groups these lines by source and user name, and the SSH brute-force rule encodes the “one source, many names” pattern as a detection.

How to stop it

You cannot stop strangers from asking; you can make the answer irrelevant and quiet.

• Turn off password authentication. PasswordAuthentication defaults to yes, so set it explicitly, and set KbdInteractiveAuthentication no as well if PAM is in play — the manual notes that PAM keyboard-interactive authentication usually serves an equivalent role to password authentication.
• Keep PermitRootLogin at or below the default of prohibit-password, which disables password and keyboard-interactive authentication for root.
• Restrict who may log in at all with AllowUsers; by default login is allowed for all users, and the directive also accepts USER@HOST patterns with CIDR host criteria.
• Leave PerSourcePenalties enabled — penalties are on by default, and a client that disconnects after unsuccessful authentication attempts is refused for 5 seconds, accumulating up to a maximum of 10 minutes.
• Keep LoginGraceTime (default 120 seconds) and MaxAuthTries (default 6) tight so each connection costs the scanner time and gives it few tries.
• Best of all, do not expose 22 to the whole internet: restrict it at the firewall or put it behind a VPN or bastion. Moving to a non-standard port reduces log volume but not risk.

sudo sshd -t && sudo systemctl reload ssh

Always validate the configuration before reloading, and keep an existing session open until you have proved a new one works.