Security teams should use ProxyJump as the standard way to reach private hosts through a bastion, because it keeps the connection readable, repeatable, and easier to manage than custom workarounds. Put the jump in ~/.ssh/config for common targets, use multi-hop chaining only when needed, and avoid exposing agent credentials on the jump host. The goal is controlled reachability with less operational drift.
Why ProxyJump Becomes the Default Access Pattern for Private Hosts
ProxyJump gives security teams a single, explicit path through a bastion instead of a pile of one-off SSH commands, aliases, and manual tunnel steps. That matters because the connection path stays visible in configuration, easier to review, and less likely to drift over time. For teams managing private infrastructure, the value is repeatability as much as reachability, especially when the jump pattern is codified in Ultimate Guide to NHIs style control thinking.
When the access route is standardized, operators can reason about who may reach which host, through which intermediary, and under what account context. That is materially better than ad hoc bastion workflows, which tend to hide exceptions inside shell history, manual copy-paste steps, or undocumented local setup. The end state should be controlled reachability with fewer hidden variations.
ProxyJump also fits the operational reality of SSH better than bespoke workarounds because it preserves the native client workflow. You still use familiar SSH config, host aliases, and keys, but the jump host is an explicit transit point rather than an informal habit. That makes peer review, onboarding, and incident response easier because the access pattern is readable before anyone connects.
How to Structure the SSH Config Without Reintroducing Drift
The best implementation is usually to define common targets in ~/.ssh/config, with the private host pointing to the bastion as its jump point. That way the operator runs a normal SSH command, while the client handles the intermediary connection consistently. For a multi-hop path, chain jumps only where the network path truly requires it, since each extra hop increases the number of places where troubleshooting and trust assumptions can go wrong.
Good structure is not just convenience, it is governance. A tidy config reduces the temptation to invent temporary commands, and temporary commands are where access workflows become fragile. If a team has to remember different connection strings for every subnet, environment, or project, the bastion quickly becomes a source of operational entropy instead of a control point.
Security teams should also treat host key handling, key ownership, and bastion policy as part of the same design. If the bastion is only a transit layer, it should not become a place where broader credentials or unmanaged access paths accumulate. The cleaner the SSH path, the easier it is to keep authentication and routing decisions separate from the host itself.
Risk and Threat Considerations
Ad hoc bastion workflows create hidden access paths, inconsistent logging, and a larger chance that operators will bypass the intended control plane when something breaks. That raises both exposure and detection risk, because the organisation may know a host is reachable without being able to explain precisely how the path was established.
Failure mechanism: Manual jump procedures tend to decay into local exceptions, exposed forwarding rules, or copied credentials on intermediary systems, which undermines least-privilege access and makes compromise paths harder to contain.
Impact: If the bastion or its operator workstation is abused, the attacker may gain a reliable stepping stone to private hosts, and defenders may lose clarity about which sessions were legitimate versus improvised.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | ProxyJump access still depends on SSH keys and credential handling for bastion transit. |
| NHI-03 — Non-Human Identity Access Governance | Bastion-based host access is an access-governance problem for SSH-capable machine accounts and keys. | |
| NHI-06 — Privileged and Sensitive Actions | Jump-host access often reaches privileged systems, so control of elevated SSH paths is material. | |
| Recommendation — Store SSH credentials in managed secrets and rotate any key material used for jump access. Define and review which jump paths and host targets each SSH identity may use. Restrict privileged SSH routes to approved jump patterns and remove ad hoc exceptions. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication, and Access Control | Standardized jump access is an access-control design for reaching private hosts. |
| PR.PS — Platform Security | Private-host reachability depends on hardened bastion and workstation platforms. | |
| DE.CM — Continuous Monitoring | Readable, repeatable access paths improve monitoring of who reached which host. | |
| Recommendation — Enforce least-privilege SSH access through approved jump paths and managed host definitions. Harden the bastion and client systems that terminate or initiate jump connections. Monitor bastion and SSH session activity for unexpected routes and interactive use. | ||
| CIS Controls v8 | 6 — Access Control Management | ProxyJump replaces informal access with controlled, reviewable host access. |
| 8 — Audit Log Management | Jump-host sessions should be logged so private-host access is attributable. | |
| Recommendation — Centralize SSH access paths and remove unmanaged bastion workflows. Keep bastion and SSH session logs for all jump-mediated private-host access. | ||
| NIST Zero Trust (SP 800-207) | 3 — Zero Trust Architectural Components | ProxyJump is an explicit intermediary trust boundary for private-host access. |
| Recommendation — Treat the bastion as a policy-enforced transit component rather than a trusted shortcut. | ||
Practitioner Guidance
What to prioritise: Standardise the SSH path first, then decide which hosts deserve direct ProxyJump entries and which require multi-hop chaining. If the path cannot be represented clearly in config, treat that as a design problem, not an excuse for another temporary bastion workaround.
What to verify: Confirm that the bastion does not become a credential repository, that private-host access is limited to the intended jump chain, and that operators can reproduce the path from a clean workstation without manual steps. If the access model depends on tribal knowledge, it is already drifting.
Practitioner takeaway: The main benefit of ProxyJump is not just convenience, it is that access becomes reviewable and repeatable, which is what makes a bastion workable at scale.
Related resources from NHI Mgmt Group
- How should security teams log privileged SSH access from bastion hosts?
- How should security teams implement agentless access to private EC2 instances without relying on bastion hosts?
- How should security teams design private infrastructure access without exposing bastion hosts to the public internet?
- How should security teams decide whether JIT access is safe for non-human identities?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
