Authentication logs help explain login attempts, privilege changes, and session activity. They are security-sensitive evidence, but one line rarely establishes a user's intent or proves that an account was compromised.
Logging · Lesson 5
Authentication Logging
Learn how to locate, interpret, and safely correlate Linux authentication records.
Locating Authentication Records
Debian-family syslog configurations commonly route authentication events to /var/log/auth.log; Red Hat-family configurations commonly use /var/log/secure. A systemd journal may retain the same events with unit and process metadata, and centralized logging may hold the authoritative copy.
Discover the local destination and query the relevant service, for example:
$ sudo journalctl -u ssh.service --since '1 hour ago'
$ sudo less /var/log/auth.log
The SSH unit can be named ssh.service or sshd.service. Permissions commonly restrict these records because they expose account and access details.
Where must Linux authentication events always be stored?
Interpreting an Event
A traditional record might contain:
Jan 31 10:37:50 icebox pkexec: pam_unix(polkit-1:session): session opened for user root by (uid=1000)
This identifies the time, host, emitting program, PAM module and service, requested session user, and originating UID. It does not by itself identify the human behind UID 1000 or prove that the action was malicious. Resolve the UID against account records valid at the incident time and correlate terminal, remote address, session, and surrounding events.
What does uid=1000 establish in this record?
Investigating Success and Failure
Search for both accepted and rejected attempts in a bounded time range. For SSH, also examine connection source, authentication method, target account, session open and close, and service restarts. Repeated failures can be user error, automation with stale credentials, scanning, or an attack; rate alone does not select one explanation.
last and lastb can summarize records from wtmp and btmp where maintained, but those binary databases have their own retention and integrity limits. Cross-check them with journal or syslog records and centralized sources.
What should repeated failed logins be correlated with?
Preserving and Responding
If an incident is suspected, record host time and timezone, preserve original logs and metadata, and secure any exported copy. Avoid editing evidence in place. Account locks, firewall changes, and session termination can interrupt legitimate access or alert an attacker, so follow the incident-response process and retain a recovery path.
How should authentication evidence be handled during an investigation?
Lesson complete
You finished Authentication Logging
You can now examine authentication events without overclaiming what one record proves.
Discover the locally configured authentication-log destination.
Interpret identity, service, method, and session fields in context.
Correlate failed and successful activity across retained sources.
Preserve evidence and coordinate disruptive response actions.
Keep your learning progress
Create a free account to save this lesson and continue learning on any device.
Create a free account