Back to lessons

Cybersecurity Triage

Show Successful Logins and sudo Use

You need a compact access timeline from auth logs that includes successful SSH logins and sudo commands.

Command

grep -E 'Accepted publickey|sudo:' fixtures/user-access-audit/logs/auth.log

What changed

Nothing changes. The command filters the fixture-local auth log for successful access and privilege-use lines.

Danger

safe

When to use it

Use during first response, server handoff, or after a suspicious change to build a quick access timeline.

When not to use it

Do not treat this as a complete audit trail; also check rotated logs, system journal, and identity-provider logs on real systems.

Undo or recovery

No undo needed because this command is read-only.

Expected output

Accepted SSH login lines and sudo command lines in log order.

demo script

Disposable terminal steps

  1. sed -n '1,8p' fixtures/user-access-audit/logs/auth.log
  2. grep -E 'Accepted publickey|sudo:' fixtures/user-access-audit/logs/auth.log

simulated output

What it looks like

disposable vessel
::fixture-ready::
$ sed -n '1,8p' fixtures/user-access-audit/logs/auth.log
Jun 25 08:11:04 host sshd[1401]: Accepted publickey for alex from 198.51.100.21 port 51244 ssh2
Jun 25 08:12:19 host sudo:     alex : TTY=pts/0 ; PWD=/srv/app ; USER=root ; COMMAND=/usr/bin/systemctl reload nginx
Jun 25 09:03:55 host sshd[1519]: Accepted publickey for deploy from 198.51.100.45 port 44920 ssh2
Jun 25 09:04:02 host sudo:   deploy : TTY=pts/1 ; PWD=/srv/app ; USER=root ; COMMAND=/usr/bin/journalctl -u app.service
Jun 25 09:42:30 host sshd[1660]: Failed password for invalid user oracle from 203.0.113.19 port 39120 ssh2
Jun 25 10:15:14 host sshd[1722]: Accepted publickey for breakglass from 198.51.100.99 port 52001 ssh2
Jun 25 10:16:02 host sudo: breakglass : TTY=pts/2 ; PWD=/root ; USER=root ; COMMAND=/usr/bin/passwd alex
::exit-code::0
$ grep -E 'Accepted publickey|sudo:' fixtures/user-access-audit/logs/auth.log
Jun 25 08:11:04 host sshd[1401]: Accepted publickey for alex from 198.51.100.21 port 51244 ssh2
Jun 25 08:12:19 host sudo:     alex : TTY=pts/0 ; PWD=/srv/app ; USER=root ; COMMAND=/usr/bin/systemctl reload nginx
Jun 25 09:03:55 host sshd[1519]: Accepted publickey for deploy from 198.51.100.45 port 44920 ssh2
Jun 25 09:04:02 host sudo:   deploy : TTY=pts/1 ; PWD=/srv/app ; USER=root ; COMMAND=/usr/bin/journalctl -u app.service
Jun 25 10:15:14 host sshd[1722]: Accepted publickey for breakglass from 198.51.100.99 port 52001 ssh2
Jun 25 10:16:02 host sudo: breakglass : TTY=pts/2 ; PWD=/root ; USER=root ; COMMAND=/usr/bin/passwd alex
::exit-code::0

YouTube Short

Build an access timeline.

Filter auth logs for accepted SSH logins and sudo lines so real access stands apart from failed background noise.

LinkedIn hook

Access reviews need both who logged in and who elevated privileges.

Question: Do you combine successful SSH logins and sudo lines when reviewing access?

experiments

A/B tests to run

Metric: save_rate

A: Logins plus sudo.

B: Build the access timeline first.