ProxyCommand is the older OpenSSH mechanism for opening a connection through an intermediate host by running an arbitrary command. It is more flexible than ProxyJump, but also more verbose and harder to maintain. Teams usually prefer it only when they need a custom transport or nonstandard connection flow.
How ProxyCommand Works
ProxyCommand is an older OpenSSH connection pattern that hands the client an arbitrary command to establish a session through an intermediate host. That flexibility makes it useful for unusual routing, but it also means the transport path is defined in configuration rather than by a simpler built-in proxy abstraction.
In practical terms, the command can wrap almost anything that produces a byte stream to the target system. That is why it has historically been used for custom bastion flows, legacy jump logic, or environments where the connection path cannot be expressed cleanly with newer SSH options.
The trade-off is maintainability. Because the mechanism is command-driven, small changes in hostnames, arguments, quoting, or environment can alter the connection behaviour in ways that are harder to review than a more explicit SSH routing model.
Where It Fits in SSH Connectivity
ProxyCommand sits in the connection layer, not the authorization layer. It decides how the SSH client reaches the destination, while the usual SSH controls, keys, host verification, and server-side access rules still determine whether the session is accepted.
That separation matters because the proxy path can be operationally invisible if teams treat it as just another convenience setting. A working SSH login does not mean the chosen route is simple, stable, or easy to audit.
Compared with ProxyJump, ProxyCommand is generally the more manual option. ProxyJump is easier to read and standardise for ordinary jump-host scenarios, while ProxyCommand remains the escape hatch when the transport needs custom handling or a nonstandard intermediary workflow.
For teams documenting SSH architecture, the important question is not only whether the connection succeeds, but whether the intermediate command is understandable enough for future operators to maintain and review.
Operational Trade-offs and Maintenance Concerns
ProxyCommand’s main advantage is flexibility. It can support legacy tunnels, wrapper scripts, chained tools, or bespoke network paths that do not map neatly to a simple jump configuration.
Its main downside is complexity. Because the effective connection logic may live inside shell syntax or helper scripts, the real transport path can be harder to test, harder to version-control cleanly, and easier to break during environment changes.
That complexity also increases the chance of configuration drift. If different teams encode different ProxyCommand variants for similar hosts, the SSH estate becomes harder to standardise and the connection logic can become a hidden dependency.
When teams need ordinary jump-host connectivity, simpler mechanisms are usually preferable. ProxyCommand earns its place when the transport itself is the problem being solved, not when it is merely a legacy habit.
Risk and Threat Considerations
ProxyCommand can widen exposure because it allows arbitrary command execution as part of the connection flow. If the command string, wrapper script, or supporting environment is altered, the SSH client may be redirected through an unintended path or made to trust a weaker intermediary.
That risk is especially relevant in shared bastion, automation, or admin-workstation contexts, where a small configuration mistake can affect many sessions at once. NHIMG research shows that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, which makes tightly governed connection paths even more important.
Failure mechanism: An attacker or misconfiguration can abuse the flexibility of the proxy command to change the effective transport, insert an unintended relay, or make review and detection of the real connection path more difficult.
Impact: The result can be credential exposure, session hijack, unauthorized routing, or a harder-to-detect path into protected systems, especially where SSH trust decisions are already broad.
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 CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 4 — Secure Configuration of Enterprise Assets and Software | ProxyCommand is SSH connection configuration that must be standardized and controlled. |
| CIS 6 — Access Control Management | ProxyCommand affects how remote administrative access is routed to protected hosts. | |
| CIS 16 — Application Software Security | Command-driven transport logic can hide implementation risk inside reusable scripts and tooling. | |
| Recommendation — Restrict and review ProxyCommand settings as part of secure configuration baselines. Limit SSH proxy paths to approved administrative routes and remove unnecessary intermediaries. Review helper scripts and connection tooling for unsafe command construction and path manipulation. | ||
| NIST CSF 2.0 | PR.AC — Access Control Management | SSH proxy routing influences how authenticated users reach target systems. |
| GV.OV — Oversight | ProxyCommand requires explicit oversight because its behavior is embedded in configuration and scripts. | |
| Recommendation — Enforce approved SSH access paths and verify that proxy routing does not weaken authorization boundaries. Establish ownership and periodic review for custom SSH proxy configurations. | ||
Practitioner Guidance
What to watch for: Treat ProxyCommand as a special-case control rather than a default pattern. If the same environment can be expressed with a simpler SSH routing method, that usually reduces review burden and operational fragility.
Governance implication: The command itself becomes security-sensitive configuration and should be reviewed with the same discipline as other connection-path controls. Keep the logic explicit, documented, and limited to cases where the added flexibility is genuinely required.
Practitioner takeaway: Use ProxyCommand when you need custom transport, not when you only need a convenient jump host, because the extra flexibility is paid for in auditability and maintenance cost.
Related resources from NHI Mgmt Group
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
