Notifications
Clear all
Topic starter
08/06/2026 4:56 pm
TL;DR: Self-managed bastion host logging can capture utmp, wtmp, btmp, syslog, and auditd data, but StrongDM’s tutorial also shows how quickly the resulting audit trail becomes complex, noisy, and dependent on brittle local configuration. For IAM and NHI teams, the lesson is that visibility without governance, retention, and integrity controls is not a durable control model.
NHIMG editorial — based on content published by StrongDM: How to Configure Bastion Host for SSH Logging | Part 3 - Tutorial
Questions worth separating out
Q: How should security teams log privileged SSH access from bastion hosts?
A: Security teams should treat bastion logging as an evidence control, not just a troubleshooting feature.
Q: What breaks when bastion logs stay only on the jump host?
A: When bastion logs stay only on the jump host, the record is vulnerable to the same compromise that affects the access path.
Q: How do you know if bastion auditd coverage is actually working?
A: Auditd coverage is working when it can reliably show who changed a sensitive file, which command made the change, and when it happened, without overwhelming analysts with irrelevant events.
Practitioner guidance
- Separate evidence from the bastion host Forward SSH and audit logs to a secondary system so compromise of the jump box does not destroy the only record of privileged activity.
- Limit auditd to high-value targets Track only the files, directories, and command patterns that matter for privileged access investigations, such as account databases and sensitive admin paths.
- Harden session-record storage Avoid world-writable log directories and restrict read and delete permissions so captured sessions cannot be erased by ordinary users.
What's in the full article
StrongDM's full blog post covers the operational detail this post intentionally leaves for the source:
- Exact rsyslog configuration steps for forwarding SSH logs to Papertrail.
- Command-by-command auditd setup for monitoring /etc/passwd and shared directories.
- Interactive session recording script details, including the shell profile changes used to capture commands.
- Practical examples of verifying logs with last, ausearch, aureport, and tail.
👉 Read StrongDM's tutorial on bastion host SSH logging and audit setup →
Bastion host SSH logging: is your audit trail actually defensible?
Explore further
08/06/2026 6:50 pm
Self-managed bastion logging is only as strong as its off-host evidence path. A bastion can collect utmp, wtmp, btmp, syslog, and auditd data, but that does not make the control defensible if the host remains the primary repository. The governance issue is survivability of evidence, not volume of evidence. In identity terms, the control fails when the audit trail depends on the same system that the privileged actor can reach. The practitioner conclusion is that the integrity of access history must outlive the bastion itself.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, which shows how slowly remediation can lag behind exposure.
A question worth separating out:
Q: Who is accountable when a bastion audit trail is incomplete?
A: Accountability sits with the team that owns privileged access design, logging retention, and review. If bastion logs are incomplete, local only, or writable by ordinary users, the control design is deficient even if the host is technically logging. Governance requires evidence that survives incidents and can be audited independently.
👉 Read our full editorial: Bastion host SSH logging shows the limits of self-managed audit trails
