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
sed -n '1,8p' fixtures/user-access-audit/logs/auth.loggrep -E 'Accepted publickey|sudo:' fixtures/user-access-audit/logs/auth.log
simulated output
What it looks like
::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.