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 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 its configured protocols, with Oracle and VNC beta disabled, 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	Check its protocol settings. Oracle and VNC beta are disabled.
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 can enable multiple listeners, 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, Cassandra, or Oracle beta). 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	No
Oracle beta	`1521`	Opt-in	Opt-in
PostgreSQL	`5432`	Yes	Yes
RDP	`3389`	Yes beta	Yes
Redis	`6379`	Yes	Yes
RESTCONF	`8444`	Yes	No
SQL Server (MSSQL)	`1433`	Yes	Yes
SSH	`22`	Yes	Yes
Telnet	`23`	Yes	Yes
VNC beta	`5900`	Opt-in, VeNCrypt X509Plain	Opt-in
WinRM	`5986`	Yes	No

Native authentication

Every native connection must prove the checkout owner’s password or supported SSH key. The user%host username selects the route; an active checkout alone does not authenticate the client. native_auth: ldap checks a directory password, while native_auth: bridge_credentials checks the separate bridge_auth_password. MongoDB and Oracle native access use Bridge credentials. See checkout authentication.

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.

VNC browser and native access are opt-in betas for development and testing, disabled by default and not production-ready. See VNC beta for tested clients and target requirements.