Your server's authentication logs record every login attempt, successful or failed. Reviewing them regularly — or better, automating the review — is how you catch brute-force attempts, unusual login times, or unauthorized access before they become a bigger problem.
Prerequisites
- Ubuntu or Debian VPS
- Root or sudo access
Step 1 — Locate the Auth Log
On systemd-based Ubuntu/Debian, authentication events are in the journal, and also typically in:
/var/log/auth.log
Step 2 — View Recent Login Attempts
sudo grep "sshd" /var/log/auth.log | tail -50
Or via journalctl:
sudo journalctl -u ssh --since "24 hours ago"
Step 3 — List Successful Logins
last -a | head -20
Step 4 — List Failed Login Attempts
sudo grep "Failed password" /var/log/auth.log | tail -50
Step 5 — Count Attempts by Source IP
sudo grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head -10
This quickly reveals which IPs are hammering your server — useful for manually banning persistent offenders or confirming Fail2Ban is catching them.
Step 6 — Install logwatch for Daily Summaries
sudo apt install logwatch -y
Run an on-demand report:
sudo logwatch --detail high --range today --service sshd --print
Step 7 — Enable Daily Email Reports (Optional)
sudo nano /etc/cron.daily/00logwatch
/usr/sbin/logwatch --output mail --mailto [email protected] --detail high
This requires a working local mail setup (e.g. postfix configured to relay outbound mail).
What to Look For
- A sudden spike in failed logins from a single IP or range
- Successful logins at unusual hours or from unfamiliar countries
- Logins to accounts that shouldn't normally be used interactively (e.g. service accounts)
- New entries in
authorized_keysyou don't recognize
Common Errors
auth.log is empty or missing — some minimal images only log to the systemd journal; use journalctl instead, or install rsyslog.
Best Practices
- Pair log monitoring with Fail2Ban so repeat offenders are blocked automatically, not just logged
- Ship logs off-server for critical production systems, so an attacker can't erase evidence
- Review logs on a fixed schedule, not just reactively
FAQ
Is a few failed SSH attempts per day normal?
Yes — automated internet-wide scanning constantly probes port 22/2222 on every public IP. Fail2Ban handles this automatically; the concern is sustained targeted activity or successful unauthorized logins.
Continue Reading
- How to Install and Configure Fail2Ban
- VPS Security Checklist for Beginners
- How to Detect and Remove Rootkits on a Linux VPS
Browse more articles in Server Security & Hardening.
