Use case

SSH access to a single server

The problem

An engineer needs a shell on one remote server — not standing network membership that happens to include SSH reachability.

Why traditional network access is excessive here

A private overlay network grants IP-level reachability to every device on it; SSH is then just one of many things that happens to be reachable. That is more connectivity than an SSH-only need requires.

How TunnelCrib handles it

The TunnelCrib Agent on the target server advertises its ssh Service (port 22 by default). The requesting Client is authorized for that Device and Service only.

Setup example

$ tunnelcrib connect prod-web-01:ssh

device identity verified
direct Tunnel negotiated
Service Tunnel active
localhost:49318

$ ssh -p 49318 user@localhost

Authorization example

Access is scoped per Client, per Device, per Service — an engineer authorized for SSH on one server is not automatically authorized for SSH (or any other Service) on any other Device.

User experience

The engineer's normal SSH client and credentials/keys are used against localhost:<port>; TunnelCrib carries the TCP connection but does not participate in the SSH session's own authentication.

Audit trail

Connect and session-close events are recorded (see audit events).

Security considerations

TunnelCrib's own Device-identity and per-session key pinning (see transport) authenticate the Tunnel itself; the SSH session inside it still uses its own independent authentication.