Triage Linux SSH and Sudo Activity

SSH and sudo records provide useful context about remote access and privilege use. Review them together: an SSH authentication event identifies an access attempt or session, while sudo records can show a later command run with elevated privileges.

This walkthrough uses the systemd journal and read-only commands. Distribution logging differs: Debian and Ubuntu commonly write authentication messages to /var/log/auth.log; RHEL-family systems commonly use /var/log/secure when a syslog service is configured. Journal retention and collection policy determine which records are available.

Journal review: Compare SSH authentication and sudo records using their UTC timestamps, account, source, and command.

---

Step 1: Set the Host and Time Basis

01

Record the System and Its Time Configuration

Scope

Record the case ID, host name, affected account, and time range. Compare the host’s clock and time zone with the alerting platform, then use UTC when building the shared timeline. Start with a short window around the alert; widen it only when the evidence calls for it.

hostnamectl --static
timedatectl status
sudo journalctl --list-boots

❯ View Expected Console Output

app-17
Local time: Mon 2026-10-05 09:20:00 CEST
Universal time: Mon 2026-10-05 07:20:00 UTC
Time zone: Europe/Zagreb (CEST, +0200)

Use journalctl --utc in the following queries to compare entries
with other systems on a consistent time basis.

---

Step 2: Query SSH and Sudo Records for a Bounded Window

02

Read the Relevant Journal Entries

Log Review

Query SSH daemon and sudo records separately so each result is easy to review. The _COMM match filters on the process name. Use the case’s actual start and end times instead of the example 24-hour interval when investigating a real alert.

sudo journalctl --since '24 hours ago' --until now --utc \
  --no-pager -o short-iso-precise _COMM=sshd

sudo journalctl --since '24 hours ago' --until now --utc \
  --no-pager -o short-iso-precise _COMM=sudo

❯ View Expected Console Output

2026-10-05T07:22:18.412345Z app-17 sshd[2481]: Failed password for ...
2026-10-05T07:23:04.512345Z app-17 sshd[2510]: Accepted publickey for ...
2026-10-05T07:25:11.612345Z app-17 sudo[2634]: user : TTY=pts/1 ; COMMAND=...

---

Step 3: Inspect the Authentication and Privilege Details

03

Separate Attempts, Sessions, and Elevated Commands

Analysis

For SSH, note whether authentication succeeded, the account, source address, authentication method, and any session open or close messages. For sudo, record the invoking account, target user, terminal, working directory, and command when logged. A failed attempt is not a successful session, and a sudo command is not suspicious solely because it is privileged.

SSH fields to capture:
- Timestamp in UTC
- Success or failure and authentication method
- Account and source address
- Session opened / closed when recorded
- Host and SSH service log source

Sudo fields to capture:
- Invoking account and target user
- TTY, working directory, and command
- Timestamp, host, and source log record
- Whether the command matches an approved task

❯ View Expected Console Output

Example finding:
An accepted public-key login for ops-user came from a new source
address. A sudo command followed two minutes later; owner and
maintenance authorization are not yet confirmed.

---

Step 4: Correlate with Other Host and Identity Evidence

04

Check Nearby Sessions and Approved Work

Correlation

Compare the same time window with the change calendar, access gateway, identity provider, endpoint telemetry, and the system’s expected role. A source address may identify a VPN, jump host, NAT gateway, or scanner rather than a person’s workstation. Check the account owner and key-management record before calling a public-key login unauthorized.

last -Fai | head -n 30
sudo lastb -Fai | head -n 30

❯ View Expected Console Output

last    reads recorded login sessions when the system maintains them.
lastb   reads failed-login records when the system maintains them.

These files may be absent, rotated, incomplete, or outside retention.

---

Step 5: Handle Missing Logs and Write the Handoff

05

Check the Distribution's Other Authentication Log

Collection Check

If the journal query is empty, confirm the service name, time window, journal access, and retention first. Some systems forward authentication messages to traditional log files instead of, or in addition to, the journal. Read only the path used by the host’s logging configuration; do not assume that every distribution has both files.

# Debian / Ubuntu, when configured:
sudo grep -E 'sshd|sudo' /var/log/auth.log | tail -n 500

# RHEL / Fedora family, when configured:
sudo grep -E 'sshd|sudo' /var/log/secure | tail -n 500

❯ View Expected Console Output

No matching file or no entries is a collection / retention question
to investigate; it is not proof that no authentication occurred.

Use the timestamps to keep only the case interval. If the interval
spans log rotation, identify and review the relevant rotated files too.

Case handoff checklist

Include host name, exact UTC window, journal filters or file paths, account, source address, key or authentication method when present, sudo command, related session records, and the evidence location. Separate confirmed observations from unverified explanations, and name the owner for each next check.

Do not change access during evidence review

Do not edit authorized_keys, disable accounts, kill sessions, or alter SSH configuration as part of read-only triage. If access containment is needed, follow the incident lead’s approved procedure and record the authorization, time, and operator.

References

systemd journalctl manual · Debian: Security configuration and logs · Red Hat: Authentication and system logs