SSH Dynamic Port Forwarding is an SSH tunnelling method that creates a local SOCKS proxy for forwarding traffic through an encrypted SSH connection. Applications send their requests to the proxy, and the SSH client opens destination connections on demand through the remote host.
How SSH Dynamic Port Forwarding Works
SSH dynamic port forwarding turns the SSH client into a local SOCKS proxy. That matters because each application connection is opened only when needed, and the SSH session becomes the encrypted transport that carries traffic to the remote host before it exits toward the destination. The result is flexible per-connection forwarding without defining a single fixed remote target up front.
Because the proxy sits on the local machine, the security boundary is not the SOCKS listener alone but the SSH session, the authentication used to establish it, and the destinations the session is allowed to reach. In practice, dynamic forwarding is often used as a controlled way to reach internal services through a trusted jump point.
Why It Is Used for Network Access
The main appeal of dynamic port forwarding is adaptability. A single SSH tunnel can carry traffic to many different destinations, which makes it useful for ad hoc administration, troubleshooting, and controlled access to internal-only resources. It is also more convenient than configuring a separate local or remote tunnel for every target service.
This flexibility is why the technique appears in remote access, bastion, and investigative workflows. It can reduce the need to expose internal ports directly, while still allowing an operator or application to reach systems that would otherwise be unreachable from the local network.
That convenience should not be confused with authorisation. The tunnel only changes the path traffic takes; it does not by itself justify access to the destination systems or the data they serve.
Security Implications and Control Boundaries
Dynamic forwarding encrypts the in-transit segment between client and SSH server, which helps protect traffic from local network inspection. But the security value depends on the trustworthiness of the SSH endpoint, the strength of the SSH authentication, and the access policy enforced at the remote side. If the remote host is compromised or overly trusted, the tunnel can become a convenient relay into sensitive networks.
It also changes how control is exercised. A local SOCKS proxy can make outbound connections appear to originate from a single approved endpoint, so logging and network policy need to account for the tunnel rather than assuming the original client path is visible. This is especially important where organisations rely on network segmentation, proxy enforcement, or destination-based egress rules.
For the identity and host-key side of the problem, the practical question is whether the SSH session is bound to the right user, host, and key material. NHIMG’s SSH Key and SSH Certificate Management Guide is the right companion topic when the real issue is who can establish the tunnel and how SSH credentials are governed over time.
Operational Misuse and Detection Considerations
Because the proxy can carry many destination flows over one encrypted channel, the technique is also useful to attackers and insider threats that want to hide staging, pivoting, or command-and-control traffic inside legitimate-looking SSH use. The same property that makes the feature convenient for administrators can also make it harder to inspect destination choices at the network edge.
Detection usually focuses on the unusual combination of SSH plus proxy-like behaviour, unexpected long-lived sessions, or access to destinations that do not match the user’s normal role. Organisations should review whether the tunnel is permitted only from approved admin hosts, whether session logging is sufficient, and whether downstream systems can still distinguish legitimate remote administration from covert relay activity.
In environments where SSH tunnelling is a recurring pattern, MITRE ATT&CK protocol tunnelling guidance is useful for understanding how this behaviour fits into broader adversary tradecraft. NHIMG’s T1572 Protocol Tunnelling Defensive Guide explains how SSH-based tunnels are detected and constrained without breaking valid access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | SSH tunnels depend on managed authentication material and its lifecycle. |
| IA-2 — Identification and Authentication (Organizational Users) | SSH forwarding is established by authenticated administrative users. | |
| AC-4 — Information Flow Enforcement | Dynamic forwarding changes how traffic is routed and constrained between networks. | |
| Recommendation — Manage SSH authenticators so tunnel creation remains tied to controlled credential lifecycle. Require strong user authentication before allowing SSH tunnelling access. Enforce information-flow rules so SSH tunnels cannot bypass approved network paths. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | SSH dynamic forwarding affects remote access paths and network exposure. |
| Recommendation — Harden and monitor remote-access paths so SSH tunnels do not weaken segmentation. | ||
| MITRE ATT&CK | T1572 — Protocol Tunneling | SSH dynamic forwarding is a common protocol-tunnelling mechanism. |
| Recommendation — Detect protocol tunnelling and hunt for SSH sessions carrying unexpected destination traffic. | ||
Practitioner Guidance
Why practitioners should care: Treat dynamic port forwarding as a controlled network access mechanism, not as a harmless client setting. If it is allowed broadly, it can bypass normal segmentation assumptions and make internal reachability harder to observe.
What to watch for: Pay attention to tunnels that persist longer than expected, originate from non-administrative endpoints, or reach destinations outside normal support ranges. Where the tunnel is used for infrastructure access, also review the SSH credential path and host trust relationship, since those controls determine who can create the proxy in the first place.
When the use case is remote administration rather than general-purpose tunnelling, it is often clearer to frame the design around bastion access and credential governance. That makes ownership, auditing, and revocation easier to reason about than an open-ended proxy pattern.
Related resources from NHI Mgmt Group
- How should teams reduce the friction and risk of SSH access to remote devices without relying on port forwarding or exposed public endpoints?
- What breaks when SSH is hidden behind port knocking and dynamic firewall rules?
- How should security teams govern SSH port forwarding in privileged access workflows?
- How should security teams harden SSH without relying on port changes alone?
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