Security → Relay
What can the TunnelCrib Relay see?
A TunnelCrib Relay is only used as a fallback, when a Direct Tunnel cannot be established between Client and Agent (see Architecture). This page explains what that fallback path exposes.
How the Relay is built
The Relay's data-plane process, tunnelcrib-bridge, is an SSH server that accepts exactly two inbound SSH connections for a session — one from the TunnelCrib Client, one from the TunnelCrib Agent's reverse tunnel — each authenticated with the connecting Device's own identity key. It bridges the Client's direct-tcpip channel to the Agent's forwarded-tcpip channel, and nothing else: no shell, exec, or PTY access is permitted.
What we can state precisely today: the Bridge cannot execute commands on, or gain shell access to, either endpoint — its permitted operation is strictly limited to forwarding the two SSH channels. It is ephemeral (fresh host identity per process) and self-terminating on a session timeout or teardown. The TunnelCrib-hosted Relay always uses a fixed 30-minute timeout. A Private Relay operator can configure a different timeout for their own infrastructure via the RELAY_BRIDGE_TIMEOUT environment variable (default also 30 minutes) — this only applies when running your own Relay, not the TunnelCrib-hosted one.
The Client and Agent now run a second, inner SSH session end-to-end through the Bridge's two channels. Rather than each hop terminating SSH independently and handing the Bridge decrypted Service bytes to forward, the Client opens a single channel through the Bridge and runs a fully authenticated, host-key-pinned SSH session over it directly with the Agent — the same mutual-authentication and pinning used by a Direct Tunnel (see
Device identity). The Bridge still terminates its own two outer SSH connections (that part of the trust chain is unchanged), but the bytes it forwards between them are themselves an opaque, already-encrypted SSH stream it holds no key material for. The Bridge cannot decrypt Service traffic on a relayed Tunnel.
What the Relay never sees
- The Service payload itself — the inner Client↔Agent SSH session is encrypted and authenticated independently of the Bridge's own two connections, so the Bridge only ever forwards opaque bytes it cannot decrypt.
- The organization's WebSocket bearer token or Device private keys — the Bridge only ever receives public keys as CLI flags.
- Any Service credentials (SSH password/key, RDP credentials, database credentials) — those are exchanged inside the inner, Bridge-opaque SSH session between Client and Agent.
- Any Tunnel outside its own single session — each Bridge process is spawned per session and exits afterward.
If either side's inner SSH handshake fails — for example a host-key mismatch with the Agent's pinned identity — the Tunnel attempt fails closed. TunnelCrib never falls back to bridging unwrapped Service bytes through the Relay.
Private Relay
A Private Relay still has value even though the Bridge cannot read relayed Service payload: running your own Relay keeps the fallback hop's connection metadata (source IPs, byte counts, timing, which Agent a session was for) inside infrastructure your organization controls, rather than TunnelCrib-hosted infrastructure.
Last reviewed 2026-09-17.
