How should security teams log privileged SSH access from bastion hosts?

Why This Matters for Security Teams

Bastion hosts are often treated as the safe choke point for privileged SSH access, but that assumption only holds if the logs survive the bastion itself. For NHI Management Group, logging is an evidence control: it must prove who connected, what command paths were used, and whether sensitive files or keys were touched. Without that, a compromised bastion can hide lateral movement, credential theft, or unauthorized privilege changes.

This is why logging from a bastion cannot stop at syslog or shell history. Security teams need off-host retention, integrity protection, and correlation with identity events so the audit trail remains usable after compromise. That aligns with the evidence-preserving approach discussed in the Ultimate Guide to NHIs and with the access-control expectations in the OWASP Non-Human Identity Top 10. In practice, many security teams discover log tampering only after the bastion has already been used as the attacker’s hiding place.

How It Works in Practice

Effective bastion logging starts with treating the host as untrusted once privileged access begins. Capture authentication events, interactive shell activity, command execution, session metadata, and file changes that affect keys, configs, and privilege paths. Forward those records in near real time to an external log pipeline, SIEM, or append-only storage so the bastion cannot delete or rewrite its own trail. That is the operational lesson behind the attack patterns highlighted in 52 NHI Breaches Analysis.

For practical implementation, teams usually combine several layers:

• SSH daemon logs for login success, failure, source IP, and key-based authentication events.
• Session recording or command logging for privileged shell activity, especially when root escalation is allowed.
• File integrity monitoring on authorized_keys, sudoers, config files, and credential material.
• Centralized forwarding with time sync, hash chaining, or immutability controls to preserve admissibility.

Current guidance suggests that logging should also be tied to identity context, not just host telemetry. If the bastion brokers access for humans and automation, map each session to the originating user, service account, or NHI, then enforce short-lived authorization and revoke access as soon as the task ends. The NIST Zero Trust Architecture guidance supports this direction by emphasizing continuous verification rather than implicit trust in the network edge.

Where this breaks down is on legacy bastions that lack session capture, run ad hoc admin scripts, or store logs locally without reliable forwarding, because a root-level attacker can erase both evidence and state.

Common Variations and Edge Cases

Tighter bastion logging often increases storage, parsing, and privacy overhead, so organisations need to balance investigative value against operational cost. That tradeoff becomes more visible when admins require interactive debugging, when regulated data appears in command output, or when automated systems reuse the bastion for maintenance windows.

There is no universal standard for this yet, but best practice is evolving toward risk-based logging depth. High-risk administrative paths should get full session capture and immutable retention, while lower-risk maintenance access may only need authentication, command, and file-change telemetry. The Ultimate Guide to NHIs — Key Challenges and Risks is useful here because over-privilege and poor visibility are still the conditions that turn a bastion into a blind spot.

Two edge cases deserve attention. First, in hybrid environments, bastions that bridge to cloud control planes should also log API-triggered privilege changes, not only SSH shells. Second, in environments with ephemeral admin nodes, the logging pipeline must outlive the node and the log buffer, or the record disappears with the instance. Security teams that rely only on local audit files usually find the gap after an incident, not during design.

Related resources from NHI Mgmt Group

• How should security teams run access certification for privileged accounts?
• How should security teams modernize privileged access without creating new exposure?
• How should security teams remove unused privileged access without breaking operations?
• How should security teams run access reviews for non-human identities?