ProxyCommand

What ProxyCommand Does in OpenSSH

ProxyCommand is the older OpenSSH way to reach a destination host through an intermediate system by running an external command to build the transport. That command can be as simple as a netcat-style relay or as custom as a scripted workflow, which makes it powerful but also harder to read, standardise, and support than newer built-in options.

The key distinction is that ProxyCommand is not just a routing shortcut. It is an execution hook: OpenSSH hands control to a command you provide, then uses that command’s input and output as the connection path. That flexibility is the reason teams sometimes keep it for unusual network topologies, legacy bastions, or nonstandard proxies.

How ProxyCommand Fits Into SSH Connectivity

ProxyCommand sits between the SSH client and the remote endpoint, so the connection path is defined by whatever the command returns or forwards. In practice, that means the SSH session may traverse one or more jump points, but the logic for how it gets there lives outside native SSH connection selection.

This makes ProxyCommand more expressive than ProxyJump, but also more sensitive to shell quoting, path dependencies, and local environment differences. A configuration that works on one workstation can fail on another if the command, arguments, or helper tool are not identical.

Because the command is arbitrary, it can encapsulate almost any transport logic, including bastion traversal, protocol translation, or bespoke access checks. That same freedom is also what makes it a maintenance burden in larger estates, where consistency and auditability matter.

Operational Trade-Offs and Maintenance Cost

ProxyCommand is usually chosen when native SSH routing is not enough. The trade-off is that the configuration becomes more verbose, harder to review, and more dependent on local tooling than a simpler SSH-native approach.

At scale, the main cost is not just configuration length, but configuration drift. If teams embed custom commands in multiple places, they create hidden differences in how connections are established, which can complicate troubleshooting, onboarding, and change control.

There is also an ownership issue: once a ProxyCommand depends on scripts or wrapper utilities, those supporting components become part of the connection path. Any change to the helper command can alter connectivity, logging behaviour, or even the security properties of the SSH session.

When Teams Still Use ProxyCommand

ProxyCommand remains useful when an organisation needs a custom transport path that ProxyJump cannot express cleanly. Common examples include legacy environments, nonstandard bastion flows, or situations where a helper command must perform additional setup before the SSH tunnel is available.

It can also be the right choice when the connection is not a simple one-hop jump, or when the intermediate system is not handled in a way that modern SSH jump syntax can model directly. In those cases, ProxyCommand acts as the escape hatch that preserves compatibility.

For that reason, it is best understood as a compatibility and flexibility mechanism rather than a default pattern. Teams often standardise on newer SSH constructs first, then retain ProxyCommand only where the operational requirement justifies the extra complexity.

Security Implications of Custom SSH Transport

Any mechanism that executes an arbitrary command as part of connection establishment expands the trusted surface of SSH client configuration. That does not make ProxyCommand inherently unsafe, but it does mean the command itself, its arguments, and the helper binaries it invokes deserve the same scrutiny as other access-path components.

Careless use can expose credentials, weaken host verification assumptions, or create inconsistent connection behaviour across endpoints. The security issue is usually not the SSH protocol itself, but the extra logic inserted around it.

Because the command may touch shell state, environment variables, or external tools, teams should treat it as part of the control plane for remote access, not merely as a convenience setting. The more custom the transport, the more important it becomes to know exactly what executes, where, and under whose authority.

Practitioner Guidance

Why practitioners should care: ProxyCommand is often kept for legitimate edge cases, but every custom connection path raises support and governance cost. Use it only when you need behaviour that simpler SSH-native routing cannot provide, and prefer a standardised pattern when the workflow is repeatable.

What to watch for: Watch for embedded scripts, environment-dependent helper commands, and inconsistent host definitions across teams. Those are the conditions that turn a flexible SSH feature into an operational dependency that is difficult to audit or troubleshoot.

Practitioner takeaway: If ProxyCommand is still required, document the exact command path and keep the surrounding connection logic as small and deterministic as possible.

Related resources from NHI Mgmt Group

• What is the difference between SSH ProxyJump and SSH ProxyCommand in bastion access?