SSH ProxyCommand is an OpenSSH client option that tells the client to connect through an external command instead of directly to the target host. It is commonly used to reach systems through jump hosts, bastions, or custom transports, while still presenting an SSH session to the destination.
How SSH ProxyCommand Works
SSH ProxyCommand changes the client’s connection path, not the SSH protocol itself. The client launches an external command to reach the destination through a bastion, relay, or custom transport, then hands the SSH session to that command’s network path. That makes it a connection-assembly feature with real operational and security consequences.
Because the command runs locally on the initiating system, its behaviour matters as much as the remote target. Whatever it invokes can influence where traffic goes, what host keys are seen, and which intermediate systems can observe metadata, alter routing, or interfere with the connection.
Where ProxyCommand Fits in SSH Architecture
ProxyCommand sits at the client edge of SSH connectivity. It is commonly used when direct reachability is blocked, such as segmented networks, administrative jump hosts, or environments that require a custom proxy or tunnel. In practice, it is often paired with bastions because it preserves the familiar SSH workflow while changing the transport path underneath.
This makes it useful for network design, but it also means the trust boundary expands beyond the destination host. The proxying command, intermediate host, and any wrapper script become part of the effective access path, even though the user still sees a normal SSH session.
For a broader view of SSH access governance, jump-host patterns, and SSH key handling, see SSH Key and SSH Certificate Management Guide.
Security Implications of an External Connection Command
ProxyCommand can weaken assumptions if the external command is poorly controlled. A wrapper that logs arguments, proxies through an untrusted relay, or silently rewrites connection details can expose target names, user context, or routing decisions. If the command invokes other tools, those tools may inherit secrets, environment variables, or session material needed to complete the connection.
The security model also depends on host identity remaining trustworthy through the intermediary. If an organisation treats the jump path as benign without validating how host keys are presented and checked, it can create room for misrouting, impersonation, or downgrade of the intended trust relationship.
Using a controlled SSH design also aligns with external guidance on least privilege, access control, and secure configuration. NIST SP 800-53 control families such as AC, IA, CM, and AU are relevant when the proxy path becomes part of the access architecture, and NIST SP 800-207 is a useful reference when the bastion pattern is being used to enforce explicit verification instead of implicit network trust.
Operational Trade-offs and Safe Usage Patterns
ProxyCommand gives teams flexibility, but that flexibility can become hidden technical debt. It is harder to reason about access when connection logic lives in shell commands, local config snippets, or inherited profiles rather than in a centrally reviewed access pattern. The more custom the transport, the more important it is to document who owns it and what it can reach.
In mature environments, the safest use is usually the simplest one: a narrowly scoped proxy path, a predictable bastion, and minimal custom logic in the command itself. If the connection path depends on secrets or certificates, the surrounding SSH key lifecycle should be managed carefully so that an old proxy route does not keep working after access should have been removed.
ProxyCommand is also a common place where troubleshooting and governance intersect. When a connection fails, the problem may be in DNS, routing, the proxy command, the bastion, or the destination host, so operators need a clear record of which layer owns which failure mode.
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-4 — Information Flow Enforcement | ProxyCommand changes the enforced SSH path through intermediary systems. |
| IA-5 — Authenticator Management | SSH access through proxies depends on controlled credential and key lifecycle. | |
| CM-7 — Least Functionality | ProxyCommand is a custom client-side mechanism that should be tightly limited. | |
| Recommendation — Enforce approved SSH routing paths so proxy access cannot bypass flow controls. Manage SSH keys and related authenticators so proxy-based access is revoked on time. Restrict client-side proxy logic to only the approved SSH use cases and transports. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Bastion-mediated SSH access fits the zero-trust model of explicit verification. |
| Recommendation — Treat each SSH hop as an explicit verification point instead of an implicitly trusted network path. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | SSH proxy paths are part of access control and should be governed as such. |
| Recommendation — Review and revoke SSH access paths, including bastions and proxy wrappers, as part of access control. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org