How to read auth logs

Quick answer: Authentication events live in /var/log/auth.log (Ubuntu/Debian) or /var/log/secure (AlmaLinux/Rocky), or via journalctl -u ssh. Look for "Failed password", "Invalid user" and — most importantly — "Accepted" lines from IPs you do not recognize: failures are noise, unexpected successes are incidents.

Overview

Auth logs answer two questions: who is knocking, and who got in. Every SSH attempt, sudo use and (on many setups) panel login leaves a line. Reading them weekly — or automating the reading with Fail2ban and alerts — turns the log from forensic archive into early warning.

Before you start

• Root/sudo access.
• Knowledge of your own IPs and usernames, so you can spot the foreign ones.

Step-by-step guide

1. Tail the log live:

   tail -f /var/log/auth.log          # Ubuntu/Debian
   tail -f /var/log/secure            # Alma/Rocky
   journalctl -u ssh -f               # systemd journal

2. Count failed attempts by IP:

   grep 'Failed password' /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head

3. Find successful logins:

   grep 'Accepted' /var/log/auth.log

   Verify each source IP and key/method is yours.
4. Login history: last (successful sessions) and lastb (failed) summarize both directions.
5. Check sudo usage: grep sudo /var/log/auth.log shows privilege escalations with the exact command.

Common issues

• Panic over failures: a public port 22 collects thousands of failures daily; that is background radiation. Investigate volume changes and successes, not single lines.
• "Invalid user admin/test/oracle": dictionary sweeps — mitigate with keys and Fail2ban rather than reading each one.
• Empty logs: rotated (check auth.log.1, .gz archives) or journald-only — use journalctl.

When to contact support

An "Accepted" line you cannot attribute means possible compromise — move to the incident guide and notify support if the server may affect others.

Frequently asked questions

Where are SSH login attempts logged?

In /var/log/auth.log on Ubuntu and Debian, /var/log/secure on AlmaLinux and Rocky, or in the systemd journal readable with journalctl -u ssh on any modern distribution.

Thousands of failed logins — should I worry?

Background bot noise is normal for any public SSH port. What matters is Accepted lines from IPs you do not recognize — an unexpected successful login is a real incident.

How do I see who logged in successfully?

Run grep Accepted on the auth log for method, key and source IP of each session, and use the last command for a concise login history with dates and durations.

Related articles

• What to do if your server is hacked
• How to install Fail2ban
• How to protect against brute-force attacks
• How to secure SSH access

Need a hand? Contact Cloud2Y support →