Locate and interpret authentication entries in system logs to spot failed logins and suspicious access. 16.11.2025 | reading time: 3 min When a login fails, the system tells a story in its logs; he only needs to read it. This short guide shows how to find authentication events on common Linux systems using journalctl and classic log files so he can identify failed logins, brute‑force attempts, and successful authentications. A failed SSH attack Start by reproducing a focused search: on systemd systems use journalctl and on classic syslog systems search auth.log; here are two concrete commands and sample output to run on a test host: ```bash sudo journalctl -u sshd --since "1 hour ago" | grep "Failed password" ``` Sample output: ```text Nov 16 09:12:34 server sshd[2345]: Failed password for invalid user tester from 198.51.100.23 port 51422 ssh2 Nov 16 09:12:40 server sshd[2345]: Failed password for root from 198.51.100.23 port 51423 ssh2 ``` On non-systemd Debian/Ubuntu use: ```bash sudo grep "Failed password" /var/log/auth.log | tail -n 5 ``` Sample output: ```text Nov 16 09:12:34 server sshd[2345]: Failed password for invalid user tester from 198.51.100.23 port 51422 ssh2 ``` Beyond simple greps Combine time ranges, units and fields to narrow the hunt: journalctl supports --since and --until and filters by _SYSTEMD_UNIT or _COMM, while classic logs can be sliced with grep, awk or sed; use last and lastb to review recent logins and failed attempts, faillog or pam_faillock to check PAM counters, and ausearch for auditd records so he can correlate a failed SSH password with a sudo or file access event. Infrastructure and pitfalls Remember log rotation and different distro paths: RHEL-family writes to /var/log/secure, Debian-family to /var/log/auth.log, and systemd may store binary journals under /var/log/journal; also watch timezones, forwarded logs, and rate-limited messages, and consider centralizing with rsyslog or syslog-ng to keep evidence when hosts are compromised. Next steps for the investigator After identifying suspicious IPs or usernames block or throttle them (for example with fail2ban), enrich findings with whois and geoip lookups, and keep an eye on repeated patterns to tune detection rules; the log is data — query it, correlate it, and automate the most common checks. Final thought Logs are the first line of sight into authentication problems; practice parsing them until spotting anomalies becomes instinctive and consider formal training such as CompTIA Linux+ or LPIC-1 to deepen skills with intensive exam preparation at bitsandbytes.academy. Join Bits & Bytes Academy First class LINUX exam preparation. security utilities troubleshooting
