Remote Desktop

Graphical desktop access. See How users connect for native vs browser, and the Payload reference for every field.

RDP

Configure the common bsh settings. This example creates a Windows local account with Remote Desktop Users membership. Set the administrative WinRM credentials and session controls:

BSH_TARGET_HOST=win-jump.example.com
BSH_TARGET_PORT=3389
BSH_TRANSPORT_USER=britivebroker
BSH_TRANSPORT_PASSWORD_FILE=/run/secrets/windows-admin-password
BSH_WINRM_CA_CERT_PATH=/run/certs/windows-ca.pem
BSH_RDP_SECURITY=nla
BSH_RDP_ENABLE_DRIVE=true
BSH_RDP_DISABLE_PASTE=true
BSH_RDP_CLIPBOARD_SAVE_FILES=true
BSH_RDP_CLIPBOARD_MAX_FILE_MB=250
BSH_LOCK_BLOCKS_SCREEN=true
BSH_BRIDGE_RECORD_SESSION=true

bsh uses WinRM over HTTPS on port 5986 to manage the account. Bridge connects to the RDP service on port 3389. Configure Bridge to trust the RDP target’s certificate as described in the RDP reference.

#!/bin/sh
exec bsh checkout rdp --method ephemeral-user --mode bridge

#!/bin/sh
exec bsh checkin rdp --method ephemeral-user --mode bridge

Checkin disables the created account by default. Native and browser access are available. For existing directory accounts, select an AD or LDAP method that matches your permission’s provisioning behavior.

VNC beta

VNC browser and native access are opt-in betas for development and testing, disabled by default and not production-ready. Enable the selected modes in the deployment first. See VNC beta for configuration and verified clients.

Rotate a Unix-hosted VNC password with bsh

For a VNC server whose password file bsh can manage over SSH, configure the common settings and these values:

BSH_TRANSPORT=ssh
BSH_TARGET_HOST=desktop.example.com
BSH_TARGET_PORT=5900
BSH_TRANSPORT_PORT=22
BSH_TRANSPORT_USER=britivebroker
BSH_TRANSPORT_KEY_FILE=/run/secrets/ssh-admin-key
BSH_TRANSPORT_SUDO=true
BSH_KNOWN_HOSTS=/etc/britive-broker/known_hosts
BSH_VNC_USER=desktop
BSH_VNC_PASSWD_PATH=/home/desktop/.vnc/passwd
BSH_LOCK_BLOCKS_SCREEN=true

The target needs vncpasswd with its -f option. Each checkout changes the server’s shared password. Checkin rotates it again, affecting other users of that password file.

#!/bin/sh
exec bsh checkout vnc --method rotate-password --mode bridge

#!/bin/sh
exec bsh checkin vnc --method rotate-password --mode bridge

Use an existing vaulted VNC password

bsh’s VNC method rotates the target password. If another system manages that password, submit the vaulted credential through the API instead:

{
  "transaction_id": "txn-vnc-001",
  "protocol": "vnc",
  "username": "alice",
  "target_host": "desktop.example.com",
  "target_port": 5900,
  "target_password": "vncPass1",
  "native_auth": "bridge_credentials",
  "bridge_auth_password": "<separate-Bridge-password>",
  "native_enabled": true,
  "browser_enabled": true,
  "lock_blocks_screen": true,
  "record_session": true,
  "expires_at": 2000000000
}

Submit vnc.json to POST /api/transactions using checkout-management authentication. The API returns 201 Created when it registers the checkout.

Replace the example target password with the vaulted VNC credential, containing 1 to 8 bytes. VNC targets do not use target_username. The Bridge password is separate and can be longer.

Native viewers connect to the Bridge’s VNC port, normally 5900, using alice%desktop.example.com and the separate Bridge password. They must support VeNCrypt X509Plain and verify the Bridge certificate. Browser users open Connect for the checkout. Both paths record desktop activity by default.

For a target that offers TLS before RFB, set target_tls: true and supply target_ca_cert when it uses a private CA. Otherwise, keep the target connection on a trusted private network or protected transport. Clipboard transfer, file transfer, and command filtering are unavailable.