Authentication Logging

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.

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.

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.

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.

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.

Summary

You can now examine authentication events without overclaiming what one record proves.

1. Discover the locally configured authentication-log destination.
2. Interpret identity, service, method, and session fields in context.
3. Correlate failed and successful activity across retained sources.
4. Preserve evidence and coordinate disruptive response actions.