MYTHOSChoose the right log source
Ubuntu installations can record SSH events in the system journal and, where a syslog service is configured, /var/log/auth.log. A missing auth.log file is not proof that SSH is unlogged. Determine how this server stores authentication events.
Read a bounded window
sudo journalctl -u ssh --since '24 hours ago' --no-pagerConfirm the actual unit name if this is empty. For an initial review of common failure messages:
sudo journalctl -u ssh --since '24 hours ago' --no-pager |
rg -i 'failed password|invalid user|authentication failure'Use grep -Ei with the same pattern if ripgrep is not installed. This text filter is a convenience, not a comprehensive parser for every OpenSSH or PAM event format.
Examine the pattern
Record the timestamp, username, source address and authentication method. Many attempts for common usernames from an unexpected internet source are different from one authorised administrator using the wrong key. Behind a relay or proxy, the observed source may be the relay rather than the original client.
Check whether unexpected successful logins followed the failures. A count of failures alone cannot answer whether someone gained access. Correlate with the user's expected work and the server's actual network exposure.
Verify logging with a controlled event
From an authorised client, make one deliberately unsuccessful login to your own test account during a known time window. Do not trigger repeated attempts that could lock out a production account. Confirm the expected event appears, then perform a normal successful login.
This validates that you are reviewing the correct log and timestamps. If no event appears, investigate unit selection, forwarding, journal retention and authentication configuration.
Respond to a concerning pattern
Review firewall exposure, key-only access and account permissions. Use the incident process for unexplained successful sessions. Rate-limiting tools can reduce repeated attempts but do not replace strong authentication or patching.
Common mistakes
Deleting logs to remove noise destroys evidence. Counting only the words Failed password misses other authentication methods. Assuming every private address is trusted overlooks compromised internal clients. Do not share full authentication logs publicly; redact usernames, addresses and unrelated business details.
Retention limit
The journal may be volatile or have limited disk retention. Document that limitation rather than claiming a clean history from a short log window. Central collection can extend visibility if you already operate a free monitoring system.
Official references
Consult the current vendor documentation if your version or screen differs.
Documentation-based draft. Commands have not all been executed against the named products in a lab. Validate configuration examples against your installed version before changing a working system.