One of the most expensive security debts I’ve watched accumulate inside enterprise environments is this: “We have root access — but no recording of it.” Standing up a jump host or bastion isn’t enough on its own. A bastion that doesn’t generate records is just a “transit point” — it doesn’t deliver any audit or incident-investigation value.
This post pulls together the session-recording pieces that have actually earned their keep for me in production:
- SSH login to the bastion
- TTY/terminal-level session recording (something like tlog)
- Privilege-escalation and command-execution records (sudo I/O logging)
- Centralized log pipeline + access model + retention
1) Goals: what do we record, what do we not?
The targets:
- Who connected? (identity)
- Where did they go? (target)
- What did they do? (commands + output/interaction)
- When did they do it? (timeline)
- With whose approval? (ticket / break-glass)
What you should NOT record:
- Passwords/secrets (mask wherever feasible)
- Key material (private keys) — which shouldn’t even be on the bastion in the first place
2) SSHD hardening: the right foundation for recording
Baseline SSHD posture:
- Password login disabled (
PasswordAuthentication no) - Root login disabled (
PermitRootLogin no) - Access only from the management segment (network policy / firewall)
- MFA/SSO (where possible) + short-lived certificates/keys
Just “producing records” on the SSHD side isn’t enough on its own; setting up the recording layer through PAM / shell wrapper / terminal recorder turns out to be more practical.
3) Terminal session recording with tlog (the general approach)
The package name varies by distribution. The concept is the same:
- The user logs into the bastion
- tlog kicks in before the shell opens
- The session I/O (commands/output) gets written in something like a JSON format
- The log collector ships it to the central pipeline
Implementation checklist:
- tlog installation
- PAM integration (tlog at login time)
- Directory and permissions for session records (root-only)
- Log shipping (e.g. Vector / Fluent Bit / rsyslog)
4) sudo I/O logging: don’t go blind “after root”
Plenty of teams only log SSH login — but the truly critical actions tend to come after the sudo.
What to target on the sudo side:
- Recording of command + stdout/stderr
- Storing I/O logs in a standard directory
- Access and retention policy
On the sudoers side (sample approach, varies by distribution):
Defaults log_outputDefaults iolog_dir=/var/log/sudo-ioDefaults use_pty
This pushes you from the “we saw the command” level up to “we saw the output too.”
5) Central log pipeline: normalize for the SIEM
Bastion session recording is “security telemetry.” When it goes to the SIEM, these fields should be standardized:
actor: user (SSO id, email or uid)src_ip: source IPtarget: target host/servicesession_id: session identifiercommand: command (if any)tty_output: output (if any; masking should be applied)ticket: change/incident id (can be enforced as required for break-glass)
6) Retention and access model
Session records have two layers:
- Visibility: SOC/SRE need to be able to search
- Access: Access to raw session output should be very restricted
Practical approach:
- Hot search: 7-14 days
- Cold archive: 30-90 days (compliance-driven)
- Immutability/WORM: preferred for critical systems
7) Validation runbook
- Connect to the bastion as a test user:
- Run simple commands (
id,hostname,sudo -l) - Perform a short sudo operation (even a read-only command works)
- Did the bastion produce records?
- Was the tlog output written?
- Are there files in the sudo I/O directory?
- Did the records show up in the SIEM within 5-10 minutes?
- Are the actor/target/session_id fields coming through?
- How does the search performance feel?
When session recording is designed well, it gives you “evidence-based management” for both security and operations. Designed badly, it either gets ignored entirely (noise) or creates risk (raw-data leakage). Treat the design as an integrated whole: recording + transport + access + retention.