SSH

SSH (Secure Shell) is the standard way to get a command-line session on a Linux or Unix server. With the Bridge, users reach those servers through a brokered SSH session that is policy-controlled and fully recorded - they never need the server’s real credentials.

You can offer SSH two ways, and you can use either or both:

• Native mode - users connect with the regular ssh command (or PuTTY, MobaXterm, an IDE’s remote terminal, etc.) pointed at a port on the Bridge.
• Browser mode - users open a terminal right inside the Bridge web interface. Nothing to install.

Native mode

Turn on native mode and pick a port for the Bridge to listen on. Port 22 is the conventional SSH port.

ssh:
  native:
    enabled: true
    listen: "22"

A user then connects the way they always have, but to the Bridge’s address:

ssh 'alice%server.internal'@bridge.example.com

For native SSH, Bridge routes the session from the SSH username. Use <bridge-user>%<target-host> so Bridge can match the checkout and connect to the approved target.

A checkout normally carries a private_key or a target_password for the backend login. If it carries neither, set ldap_auth_passthrough and Bridge logs in with the directory password the user gave it - for hosts where access comes from a directory group (AD/SSSD) rather than a stored account.

If the user authenticates to Bridge with a public key, Bridge has no directory password to reuse. It continues SSH authentication with a masked prompt for the target password. A stored private key or target password takes precedence and does not trigger this prompt.

Host keys

Every SSH server presents a host key - a fingerprint that lets a client confirm it is talking to the same server as last time, not an impostor. The Bridge needs its own host key for native SSH.

By default the Bridge generates and stores one automatically. If you run several Bridge replicas behind a load balancer, each would otherwise generate a different key, and users would see scary “host key changed” warnings depending on which replica they hit. To avoid that, give all replicas the same host key seed so they derive the same, stable fingerprint.

ssh:
  native:
    enabled: true
    listen: "22"
    host_key_path: "/data/keys/host_key"
    host_key_auto_generate: true
    host_key_seed: "a-long-shared-secret-string"

Login attempts and banner

You can limit how many times a user may try to authenticate before the connection is dropped, set the SSH version string the Bridge advertises, and show a banner (a message displayed before login).

ssh:
  native:
    enabled: true
    listen: "22"
    max_auth_tries: 3
    server_version: "SSH-2.0-BritiveBridge"
    banner: "Authorized use only. All sessions are recorded."

Browser mode

Browser mode gives users an SSH terminal inside the web interface. You can tune how that terminal looks and how much scrollback history it keeps.

ssh:
  browser:
    enabled: true
    font_name: "monospace"
    font_size: 14
    color_scheme: "gray-black"
    scrollback: 5000

scrollback is the number of past lines a user can scroll back through in the terminal.

Shared options

These apply to both modes.

ssh:
  idle_timeout: 30m
  allow_insecure_host_key: true

allow_insecure_host_key controls whether the Bridge verifies the target server’s host key when it connects out to it. Left at the default (true) the Bridge does not verify it. That suits just-in-time targets, whose host keys are not known before the session exists, but it means the Bridge connects even when a target’s identity cannot be confirmed.

Examples

ssh:
  idle_timeout: 30m
  native:
    enabled: true
    listen: "22"
    max_auth_tries: 3

ssh:
  idle_timeout: 30m
  browser:
    enabled: true
    font_size: 14
    scrollback: 5000

ssh:
  idle_timeout: 30m
  allow_insecure_host_key: true
  native:
    enabled: true
    listen: "22"
    host_key_seed: "a-long-shared-secret-string"
  browser:
    enabled: true
    scrollback: 5000

Option reference