Notifications
Clear all
Topic starter
08/06/2026 5:03 pm
TL;DR: SSH tunneling encrypts client-to-service traffic and reduces the need to expose internal ports, according to StrongDM, but it also narrows visibility and leaves credential governance unresolved. For IAM teams, the transport layer is not the access-control layer, and that distinction matters across NHI, human, and delegated access paths.
NHIMG editorial — based on content published by StrongDM: SSH Tunnel and SSH Tunneling (Port Forwarding) Explained
Questions worth separating out
Q: How should security teams govern SSH tunneling in production environments?
A: Treat SSH tunneling as privileged access, not just encrypted connectivity.
Q: Why do SSH tunnels complicate access governance?
A: They complicate governance because they separate the security of the transport from the governance of the identity using it.
Q: What breaks when SSH access still relies on shared credentials?
A: Shared credentials break attribution, make revocation slow, and make access reviews less meaningful.
Practitioner guidance
- Separate transport approval from identity approval Require explicit approval for the identity creating the SSH tunnel, not just the endpoint or port being reached.
- Bind SSH access to named identities Eliminate shared keys and unmanaged shared accounts where possible, and map each forwarded session to a unique, revocable identity.
- Log forwarded sessions as access events Treat port forwarding as privileged access and capture session start, destination, duration, and command context.
What's in the full article
StrongDM's full blog post covers the operational detail this post intentionally leaves for the source:
- Command-line examples for local and reverse port forwarding using ssh and sdm.
- Step-by-step setup conditions for enabling port forwarding in the StrongDM console.
- Practical examples of forwarding a local client to MySQL and other remote services.
- Explanation of how local port forwarding fits into StrongDM-managed access workflows.
👉 Read StrongDM's guide to SSH tunneling and port forwarding →
SSH tunneling and access control: are your controls keeping up?
Explore further
08/06/2026 7:01 pm
SSH tunneling is a transport control, not an identity control. The article makes the case for encrypted forwarding, but the governance boundary sits elsewhere: who can create the tunnel, what they can reach, and whether the session is attributable. That means SSH tunneling can reduce exposure without reducing access risk. Practitioners should treat the tunnel as one control layer inside a broader access model, not as a substitute for it.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
A question worth separating out:
Q: What is the difference between an SSH tunnel and a VPN for access control?
A: An SSH tunnel protects a specific application or port, while a VPN usually extends network-level access across many services. For practitioners, the difference matters because VPNs and tunnels can both improve transport security without automatically solving least privilege, credential lifecycle, or session traceability.
👉 Read our full editorial: SSH tunneling secures transport, but not access governance
