Hands-on steps to find why users cannot authenticate and how to act. 16.11.2025 | reading time: 3 min When a user cannot log in, the system already tells you why if you know where to look; this guide shows him how to read that conversation and act on it. Simulate a failed SSH attempt Try a simple reproduction: from a shell run `ssh jdoe@localhost` and when prompted enter a wrong password; you will see "Permission denied, please try again." then check the log with `sudo grep "Failed password" /var/log/auth.log | tail -n 5` which prints recent failure lines such as "Failed password for jdoe from 192.0.2.5 port 54321 ssh2" enabling immediate correlation between attempt and source. Count and inspect failed records Summarize and inspect binary and text records: use `sudo lastb -n 10` to list recent bad logins from /var/log/btmp and `sudo grep "authentication failure" /var/log/auth.log | less` to read related PAM messages; for systemd systems `sudo journalctl -t sshd --since "1 hour ago"` gives a focused window and `sudo awk '/Failed password/{count[$(NF-3)]++}END{for(ip in count)print ip, count[ip]}' /var/log/auth.log` quickly shows attacker IPs. Check PAM and lockout state If the account is supposed to lock after failures, query the PAM helper: `sudo pam_tally2 --user jdoe` or on newer distributions `sudo faillock --user jdoe` to see failure counts and unlock times; if entries show repeated failures but no network traffic then inspect `/etc/pam.d/` for misconfigured modules or a stale service using old credentials. Use the audit subsystem when necessary Where simple logs stop, auditd can provide determinism: `sudo ausearch -m USER_LOGIN -sv no --success no --raw | aureport --summary` ties failed authentication syscall events to a pid and tty, and `sudo journalctl _COMM=sshd -o short-iso` helps correlate those audit records with process start and environment details for deeper forensics. Remediation and next steps After locating the cause, act: block offending IPs with firewall rules, fix PAM configuration or time skew issues, rotate compromised credentials, and consider rate limiting or fail2ban for automated response; document what he changed and run the reproduction again to confirm success. Final perspective Diagnosing failed logins is detective work with repeatable commands; sharpen this skill frequently, and consider formalizing knowledge toward certifications like CompTIA Linux+ or LPIC-1 with intensive exam preparation at bitsandbytes.academy to boost both confidence and career prospects. Join Bits & Bytes Academy First class LINUX exam preparation. security troubleshooting utilities
