How does SSH over WebSocket tunnelling work?

How the WebSocket layer and the SSH layer divide responsibilities

The tunnelling pattern is straightforward: WebSocket gives SSH a browser-friendly, proxy-friendly transport, while SSH keeps doing the real security work once the byte stream is established. The outer channel usually starts as HTTP or HTTPS and then upgrades to WebSocket, which helps it traverse infrastructure that blocks raw SSH but allows web traffic. Once the tunnel is up, SSH still negotiates its own session semantics, not the WebSocket.

This separation matters because the transport and the payload have different trust decisions. The WebSocket endpoint decides who can reach the tunnel; SSH decides who can open a shell, forward ports, or use another channel type. In practice, you should think of it as one chained access path rather than two independent controls.

What must be authenticated and authorised at each layer

Both layers need explicit attention. At the WebSocket layer, the server must decide whether the client is allowed to open the tunnel at all, often based on session state, tokens, or origin checks. At the SSH layer, the server then authenticates the user or key, applies account policy, and authorises the requested SSH capabilities.

If either layer is weak, the whole path weakens. A permissive WebSocket gateway can expose SSH to unauthorised users, while weak SSH controls can turn a well-protected gateway into a high-value conduit into internal systems. That is why logging, policy, and access review need to follow the path end to end.

For the transport side, NHIMG’s WebSocket Security Guide is useful when you need to harden the handshake, Origin checks, and per-message authorisation around the tunnel itself. For the SSH side, the SSH Key and SSH Certificate Management Guide helps with the identity material that actually authorises access once the tunnel is established.

Why tunnelling changes the security and operations picture

SSH over WebSocket is often adopted to fit restrictive networks, but that convenience also changes visibility. Network tools may see only an allowed web connection, not an SSH session, so traditional perimeter rules can miss what is happening inside the tunnel. The result is not just an alternate transport, but a different monitoring and enforcement problem.

This is also why protocol tunnelling is attractive to attackers and to defenders alike. When used legitimately, it can preserve access through proxies and application gateways. When misused, it can hide command-and-control, remote administration, or lateral movement inside traffic that looks routine to the edge. NHIMG’s T1572 Protocol Tunnelling Defensive Guide covers the defender’s view of that pattern.

Risk and Threat Considerations

SSH over WebSocket creates a layered trust boundary, and weak assumptions at either layer can expose administrative access through a channel that looks like ordinary web traffic. The main risk is not the tunnel itself, but the way it can reduce detection fidelity and widen the blast radius if the WebSocket service or SSH credentials are compromised.

Failure mechanism: An attacker who gains control of the WebSocket endpoint, or who steals the SSH credential used after the upgrade, can pivot from an apparently benign browser-compatible connection into privileged interactive access. If origin checks, authentication, or session binding are weak, the tunnel can be abused without needing a separate direct SSH path.

Impact: Compromise can enable shell access, port forwarding, service reachability, and lateral movement while blending into approved web infrastructure. Defenders may also lose reliable protocol-level visibility, which delays detection and makes incident scoping harder.

Practitioner Guidance

What to verify: Treat the WebSocket gateway and the SSH service as one access control surface. Verify who can open the tunnel, what SSH identities are accepted after upgrade, and whether the tunnel can reach anything beyond the intended administrative target.

What good looks like: The tunnel is short-lived, strongly authenticated at both layers, logged with enough context to correlate the WebSocket session to the SSH session, and restricted to the minimum destinations and commands needed for the use case.

Common mistake: Teams often harden SSH and leave the WebSocket layer permissive, or they monitor the web tier but do not retain the SSH context needed for investigation. That split creates a false sense of control.

Practitioner takeaway: If you allow SSH over WebSocket, design, log, and review it as one privileged access path, not as a harmless transport wrapper around SSH.

Related resources from NHI Mgmt Group

• When should teams prioritise NHI governance over other IAM work?
• When should organisations prioritise NHI posture management over other identity work?
• When should organisations prioritise NHI security over other identity work?
• When should organisations prioritise OAuth 2.1 over other IAM work?