Use a recording proxy architecture that terminates SSH at the proxy, re-establishes the connection to the target node, and forwards session data to an audit store. On OpenSSH fleets, this lets teams add session recording gradually while keeping existing sshd servers. The trade-off is that the proxy gains more privilege, so host checking, strong access controls, and careful operational monitoring matter.
Why a Recording Proxy Fits Legacy OpenSSH Fleets
A recording proxy is the practical pattern when you need SSH session capture but cannot replace every server at once. It centralises the control point at the connection edge, so teams can introduce recording, audit retention, and policy enforcement without changing each legacy sshd deployment. That makes the rollout incremental rather than a fleet-wide migration.
The architectural benefit is simple: one proxy layer can enforce a consistent control, while the target hosts remain standard OpenSSH systems. This is especially useful where server ownership is fragmented, patch cadence is uneven, or operational risk makes a direct host-by-host upgrade unrealistic. The proxy becomes the place where session visibility is added.
That same centralisation also changes the trust boundary. Instead of trusting every host equally for recording, you trust the proxy to observe and preserve the session transcript before forwarding traffic onward. In practice, this means the proxy design must be treated as a security control, not just a convenience component.
How the Proxy Architecture Works in Practice
In the common pattern, the user connects to the proxy first. The proxy authenticates and records the session, then establishes a second SSH connection to the target server and relays interactive traffic between the two sides. The audit store receives the recording, while the legacy host continues to process the shell session as usual.
This approach is attractive because it avoids depending on native recording support across the fleet. It also allows gradual adoption by grouping hosts behind the proxy and turning on recording where needed. For organisations that need evidence for admin actions, this is usually easier to operationalise than retrofitting every server.
There is still an important boundary to understand: the proxy can see and influence both sides of the conversation. If it is compromised, the attacker may gain broader visibility, impersonation opportunities, or a way to tamper with evidence. That is why host key validation, access control, and logging around the proxy itself are critical.
What to Verify Before You Rely on the Recording
Session capture is only useful if the recording is trustworthy and retrievable. Teams should verify that recordings are complete, time-stamped, associated with the right user or operator, and written to a store that cannot be altered by the same accounts used for day-to-day administration. Gaps in integrity are often discovered only after an incident.
It is also worth testing the operational edge cases: long-running sessions, dropped connections, command retries, and privilege escalation inside the shell. A proxy that records only the connection start and end, but not the full interaction, may create a false sense of auditability. The control has to be validated against real administrator behaviour, not just login success.
For legacy environments, the practical question is often not whether the proxy is elegant, but whether it preserves observability while keeping change risk low. If the fleet is heterogeneous, a phased rollout with explicit exception handling is usually safer than a big-bang cutover.
Risk and Threat Considerations
Recording proxies concentrate privilege and visibility, so they can become a high-value target. If the proxy is weakly controlled, an attacker may use it to intercept sessions, harvest credentials entered during administration, or manipulate audit evidence before it reaches the store.
Failure mechanism: The proxy terminates and re-establishes SSH sessions, which creates a sensitive intermediary that can observe, relay, or alter traffic if its host trust, key validation, or admin access is compromised.
Impact: A compromised proxy can undermine the integrity of session records, expose privileged activity, and expand the blast radius beyond a single legacy host to every session routed through the control point.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | SSH session recording is an audit logging problem. |
| IA-5 — Authenticator Management | Proxy-based SSH recording depends on controlling credentials and session authenticators. | |
| AC-17 — Remote Access | SSH session recording on legacy hosts is a remote-access control pattern. | |
| Recommendation — Define which SSH activities must be logged and retained for review. Manage SSH keys and credentials with rotation, protection, and revocation. Constrain remote administrative SSH through controlled access paths. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The proxy centralises privileged SSH access and requires tight account control. |
| CIS-8 — Audit Log Management | Recorded sessions must be retained, protected, and reviewable. | |
| Recommendation — Restrict and review administrative SSH access through the proxy. Centralise SSH session logs and protect them from tampering. | ||
Practitioner Guidance
What to verify: Treat the proxy as production security infrastructure and confirm that it has its own hardened administration path, tightly scoped operator access, and a durable audit destination that admins cannot rewrite. Also verify that host key checking is enforced on the re-established connection, because that is what prevents the proxy from becoming a blind forwarding hop.
What to prioritise: Start with the sessions that matter most for incident response and privilege exposure, such as privileged bastions, shared admin paths, and high-value systems. Those are the places where session recording delivers immediate value and where a failure in the proxy layer would have the largest consequence.
Practitioner takeaway: The design goal is not perfect transparency everywhere on day one, but trustworthy recording at the point where privilege concentrates, with enough control around the proxy that the audit trail remains better than the risk it introduces.
Related resources from NHI Mgmt Group
- How should security teams build an identity system of record across legacy and modern environments?
- How should security teams implement device-bound SSH access across large server fleets without relying on shared keys?
- How should security teams implement just-in-time access for SSH across production systems without slowing engineers down?
- How should security teams implement authorization for MCP servers without embedding custom logic in every service?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
