OpenSSH relies on client configuration and key distribution to forward connections through a jump host. A modern SSH proxy approach can centralise access, use certificates instead of static keys, and present a live inventory of reachable systems. The practical difference is operational. One is lightweight and familiar, while the other reduces key management overhead and expands access governance options.
How the two jump access models differ operationally
OpenSSH is typically a client-led model: the operator configures ProxyJump or ProxyCommand, distributes SSH keys, and manages direct trust relationships from the workstation outward. A modern SSH proxy changes the control point, so access can be brokered centrally, scoped more consistently, and revoked without relying on every client being configured correctly.
The practical difference is not only convenience, it is where policy lives. With OpenSSH, the jump path is often embedded in local config and key material, which makes it fast and familiar but harder to standardise. With a proxy, the access decision can be enforced at the broker, which gives teams a cleaner place to apply approvals, logging, session controls, and inventory-driven routing.
Authentication, credential handling, and reachability
OpenSSH commonly depends on static keys or user-managed certificates, so the burden sits on key distribution, rotation, and cleanup. That works well in small or stable estates, but it becomes noisy when many administrators, environments, or targets are involved. A proxy approach can reduce that burden by terminating the client connection centrally and issuing access according to current policy rather than stored per-client trust.
That shift matters because the access model changes from “who has the right key on their laptop” to “who is allowed through the broker right now.” In practice, that often means shorter-lived credentials, better separation between authentication and reachability, and a live view of which systems are currently reachable through the jump path.
Governance and control trade-offs for privileged access
OpenSSH gives you a lightweight path with minimal infrastructure, which is often the right answer when the environment is small, the user set is stable, and operational simplicity matters more than central governance. A proxy becomes more attractive when the estate is larger, access needs to be reviewed frequently, or the organisation wants one policy layer for approvals, audit, and revocation.
That is the core trade-off: OpenSSH optimises for directness, while a proxy optimises for governance. The proxy usually adds a platform dependency, so teams must treat it as a control plane that needs availability, configuration discipline, and clear ownership. In exchange, it can reduce key sprawl and make access review materially easier.
Risk and Threat Considerations
Jump access becomes risky when a static trust path is allowed to persist longer than the need for it. The main exposure is not the tunnel itself, but the combination of reusable credentials, broad reachability, and weak visibility into who can reach what through the jump host.
Failure mechanism: If local OpenSSH configuration and long-lived keys are reused across many targets, a compromised workstation or exposed private key can become a durable pivot into multiple systems.
Impact: That can increase lateral movement, slow revocation, and make access review harder, especially when the estate grows or when administrators share similar jump patterns across environments.
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, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Jump access should limit who can reach which systems. |
| IA-5 — Authenticator Management | OpenSSH and proxy models both depend on key or certificate lifecycle. | |
| AU-2 — Event Logging | A proxy centralises access decisions and should produce auditable session records. | |
| Recommendation — Enforce least privilege on jump-path access and scope each target set narrowly. Manage SSH keys and certificates with rotation, revocation, and expiration. Log jump access decisions, session starts, and revocations for review. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Centralised brokered access and live policy enforcement reflect zero trust access patterns. |
| Recommendation — Broker access through policy checks instead of trusting client-side path settings. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Jump access management depends on controlling who can reach administrative paths. |
| Recommendation — Revoke unnecessary jump access paths and review privileged connectivity regularly. | ||
Practitioner Guidance
What to verify: Decide whether your main problem is connectivity or governability. If the environment is small and stable, OpenSSH may be sufficient; if access needs approvals, revocation, and inventory visibility, the proxy model usually offers better control.
What practitioners underestimate: The biggest difference is often not protocol behaviour but operational ownership. If you adopt a proxy, treat it as a privileged control plane and confirm who owns policy, logging, certificate issuance, and outage handling.
Practitioner takeaway: Use OpenSSH when you need simple, operator-managed jump paths, but prefer a proxy when access governance, revocation speed, and centralized visibility matter more than client-side simplicity.
Related resources from NHI Mgmt Group
- What is the difference between JIT access and Zero Trust for NHIs?
- What is the difference between GitHub app access and shadow integrations using API keys or SSH keys?
- What is the difference between SSH and TLS for proxy-mediated identity-aware access?
- What is the difference between using a proxy gateway for model access and calling an AI provider directly?
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
