Protocols

The Britive Bridge sits between your users and your target systems. Instead of giving people standing credentials and direct network access, the Bridge brokers each connection: a user checks out access, the Bridge connects to the target on their behalf, and the whole session is recorded.

Each kind of system the Bridge can broker is called a protocol - SSH for Linux servers, RDP for Windows desktops, MySQL for a database, and so on. This section explains every protocol the Bridge supports, how to turn it on, and the options you can tune.

The two-mode model

Most protocols can be offered in two different ways. You choose one or both per protocol.

Native mode lets people connect using the tools they already know. The Bridge opens a listening port (a numbered “door” on the Bridge’s network address) for that protocol. Your users point their normal client at that port - the ssh command, the mysql CLI, Microsoft Remote Desktop, a database GUI like DBeaver - exactly as if they were connecting to the real server. The Bridge quietly stands in the middle, applies the access policy, and records everything. Nothing about the user’s workflow changes except the address they connect to.

A port is just a numbered endpoint on a server. A single machine can listen on many ports at once - for example port 22 for SSH and port 3306 for MySQL. When you enable native mode you tell the Bridge which port to listen on for that protocol.

Browser mode runs the entire session inside the Bridge web interface. There is nothing to install and no client to configure - the user clicks their checkout and a terminal, remote desktop, or query window opens right in the web page. The Bridge renders the session for them in the browser. This is the easiest option for users and works from any device with a web browser.

You can enable native mode, browser mode, or both for the same protocol. They are independent.

What is enabled depends on which config you start from

Bridge’s built-in defaults have every protocol off. The config files bundled in the published image do not: each one enables every protocol, so that a deployment works without editing a file first.

Which applies to you depends on the config Bridge reads:

Starting point	Protocols enabled
A config file bundled in the published image	All of them
Your own config file	Only what the file enables
No config file at all	None, and Bridge refuses to start

To run a smaller set, disable the protocols you do not want. Turning one off takes one setting per mode:

bridge.yaml

telnet:
  native:
    enabled: false
  browser:
    enabled: false

A Bridge with nothing enabled refuses to start, because at least one protocol must be on.

Check which protocols your deployment exposes before putting it in front of users. A bundled config opens a listener for every protocol, and on AWS the CloudFormation template creates a load balancer listener for each one. Disable what you do not need, and keep ClientCidr narrow. See Protocols and listeners.

A minimal configuration written from scratch looks like this:

bridge.yaml

ssh:
  browser:
    enabled: true   # in-browser SSH terminals, nothing else turned on

Idle timeout

Every protocol has an idle timeout - how long a session can sit with no activity before the Bridge automatically closes it. This protects against forgotten, unattended sessions. The default is 30m (30 minutes). You can set it per protocol.

bridge.yaml

ssh:
  idle_timeout: 15m   # close idle SSH sessions after 15 minutes
  browser:
    enabled: true

Durations are written as a number plus a unit: s seconds, m minutes, h hours. For example 90s, 30m, 2h.

The in-browser SQL client

For databases, browser mode means a built-in query window where users can run SQL and see results without installing anything. You do not turn this client on separately - it is enabled automatically whenever any database protocol has browser mode on (MySQL, PostgreSQL, CockroachDB, SQL Server, Redis, MongoDB, or Cassandra). See Databases for details.

All protocols at a glance

Protocol	Native default port	Native available?	Browser available?
Cassandra	`9042`	Yes	Yes
CockroachDB	`26257`	Yes	Yes
HTTP/HTTPS Proxy	`8443`	Yes	-
Kubernetes Exec	-	No	Yes
MongoDB	`27017`	Yes	Yes
MySQL	`3306`	Yes	Yes
NETCONF	`830`	Yes	Yes
PostgreSQL	`5432`	Yes	Yes
RDP	`3389`	Yes beta	Yes
Redis	`6379`	Yes	Yes
RESTCONF	`8443`	Yes	Yes
SQL Server (MSSQL)	`1433`	Yes	Yes
SSH	`22`	Yes	Yes
Telnet	`23`	Yes	Yes
VNC	-	No	Yes
WinRM	`5986`	Yes	Yes

Not every native listener authenticates the connecting client. SSH, NETCONF, RDP and MongoDB validate a password (or a key) before they open a session. The other database listeners, RESTCONF and WinRM do not: they read user%host from the connection, find the matching active checkout, and connect with the stored credential. A password on the wire is read and discarded.

MongoDB is in the first group because SCRAM left no choice — the client verifies Bridge’s own signature, so Bridge must hold a password to answer at all. See Databases.

So for those protocols, the control that keeps the listener shut is the network, not the protocol. The published CloudFormation template restricts every listener to a single ClientCidr for this reason. Keep that CIDR tight, and do not expose those ports to a network you do not trust.

Closing this per engine depends on whether the wire protocol can hand Bridge a password to check. PostgreSQL, CockroachDB and SQL Server can, and do, for checkouts that opt into directory-credential passthrough.

Native RDP is in beta: certain RDP features may not yet function as expected. See RDP for what that covers, and please raise anything that does not behave as you expect. Browser RDP is available for the same targets.