What breaks when bastion host logging is built from local files and shell scripts?

The trail becomes easy to fragment, hard to normalize, and dependent on the bastion staying intact. Native files can show who logged in and what changed, but they do not by themselves guarantee retention, tamper resistance, or consistent review. If the host is compromised, the evidentiary value of the record drops unless the logs already exist somewhere else.

What the logging model stops guaranteeing

Local files and shell scripts can capture useful traces, but they do not by themselves create a durable audit system. Once collection, retention, parsing, and forwarding are split across ad hoc scripts, you lose consistency in format, timing, and coverage. That makes the record harder to search, harder to correlate, and easier to miss when you most need it.

The core break is not that logs disappear immediately, it is that the logging path becomes part of the thing you are trying to trust. If the bastion host is the only place those files live, the host’s health, permissions, and compromise status directly determine whether the record is reliable. For SSH access and key governance on bastions, the operational pattern is closely related to SSH Key and SSH Certificate Management Guide.

That matters because bastions are supposed to preserve visibility across privileged access. When the visibility mechanism is homegrown, you often get partial command history rather than an evidentiary trail with stable retention and review semantics. In practice, that means the logs may tell a story, but not a story you can confidently defend after an incident.

Why local files and shell scripts fragment the trail

Shell-based logging usually depends on per-session wrappers, command hooks, or rotated text files. Those pieces can miss edge cases such as interrupted sessions, direct file edits, failed rotations, truncated buffers, or commands that execute outside the wrapper. You may still see who connected, but not necessarily everything that happened in a form you can trust across time.

Fragmentation also shows up at the review layer. Local files tend to encode events in a host-specific way, so correlation across bastions, environments, or time windows becomes manual work. That increases the chance of inconsistent interpretation, especially when one team reads raw shell output and another expects structured security telemetry.

Retention is another weak point. A text file on the bastion is only retained as long as the host survives, storage stays healthy, and the rotation path works as intended. If those assumptions are broken, your logging becomes an operational convenience rather than a dependable control.

What changes once the bastion is compromised

If an attacker reaches the bastion, local logs are now exposed to the same trust boundary as the attacker. They may be deleted, altered, delayed, or rendered incomplete before anyone inspects them. Even when the attacker does not touch the logs, the evidentiary value drops because the host itself can no longer be treated as an independent source of truth.

That is why bastion logging should be judged by where the record lands, not just by what the shell prints. A separate collector, remote write path, or protected log store reduces the blast radius of a compromised jump host. Without that separation, the bastion becomes both the access point and the evidence source, which is a poor design for incident response.

For a broader control perspective, the issue aligns with CIS Controls v8 around audit logging and account management, and with NIST SP 800-53 Rev 5 Security and Privacy Controls for auditability, access control, and system integrity.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-8 — Audit Log Management	Bastion logging is an audit-log problem with retention and review needs.
Recommendation — Centralise audit logs and protect them from local tampering or loss.
NIST SP 800-53 Rev 5	AU-2 — Event Logging	The question is about what logging should capture on a bastion host.
	AU-9 — Protection of Audit Information	Local files and scripts break when audit records are not tamper-resistant.
	AU-11 — Audit Record Retention	Retention is a core failure mode when logs live only on the bastion.
Recommendation — Define and generate the events that bastion logging must record. Store audit records where they cannot be altered by the host being logged. Retain bastion audit records for the required period outside the host.
ISO/IEC 27001:2022	A.8.15 — Logging	Bastion logging is an Annex A logging control concern in operational security.
Recommendation — Implement logging that captures access and supports later review.

Practitioner Guidance

What to verify: Treat the logging path as a control surface. Verify that bastion logs are forwarded off-host, normalized into a consistent schema, and retained in a place the bastion operator cannot silently rewrite.

Decision rule: If the bastion itself is the only durable copy of access evidence, treat the design as fragile and high-risk, even if it is operationally convenient. If the log record survives host compromise, review and incident response become materially more defensible.

What good looks like: A practitioner can reconstruct access from independent log storage, confirm retention, and compare shell records with authentication and session events without relying on one mutable text file.

Practitioner takeaway: Bastion logging fails when it is treated as a local convenience instead of an independently protected evidence stream; durability outside the host is what turns “logs” into audit evidence.