Skip to content

Connecting — SSH, databases & RDP

Once signed in, the app lists the targets your grants allow, organized by project and group and split into tabs by kind. Pick one and connect — the credential is injected for you, and the session is audited (and recorded if enabled on the target).

The simplest way to get a shell is the embedded terminal — click Built-in on the SSH target. It talks to the target over the brokered tunnel using the app’s own SSH client, so nothing needs to be installed: no OpenSSH client and no ~/.ssh/config on your machine.

Connect starts a local proxy and shows a single copyable command that reaches the target by name:

Terminal window
ssh <name>.tessera.local

The desktop keeps a small SSH config up to date for you automatically — there’s no button to press. It writes a single Host *.tessera.local block to ~/.ssh/config.d/tessera (pulled in by an Include line in ~/.ssh/config) whose ProxyCommand routes the connection through Tessera, so the name resolves without DNS. (On Windows the bundled console tessera-cli.exe is the ProxyCommand, since the GUI app can’t be one.) scp and sftp work the same way (scp file <name>.tessera.local:).

Scripting, or want a raw local port instead? The CLI covers headless connects and background tunnels.

Where:

  • <name> — the target’s name exactly as it appears in the app (for example web-prod).

For a database target, Connect opens a local port speaking the PostgreSQL or MySQL wire protocol and prints a ready-to-paste connection string. For PostgreSQL it shows a URL you can hand to psql or any GUI database client — authenticate with any user and no password:

Terminal window
postgresql://localhost:<port>/<dbname>

For MySQL connect as the local user tessera with an empty password (other usernames are rejected):

Terminal window
mysql -h 127.0.0.1 -P <port> -u tessera

Where:

  • <port> — the local port Tessera opened for this database connection (shown next to the command; changes each session).
  • <dbname> — the database to open. Tessera pre-fills it; for PostgreSQL it defaults to postgres when the target doesn’t pin a specific database.

Either way the controller injects the real database login. Queries are audited, and in a read-only session write statements are rejected.

For an RDP target, click Connect — it launches a native remote-desktop window connected through the broker. A remote-desktop client is bundled with the app on all three platforms — Windows, macOS and Linux — so nothing extra is needed. (On Linux the .deb ships its own FreeRDP under /usr/lib/tessera/freerdp; a dev or non-.deb build falls back to an xfreerdp3 on your PATH, or point TESSERA_RDP_CLIENT at a FreeRDP v3 binary.)

The Windows username and password are injected into the bundled RDP client in memory — they are never written to disk, stored in the OS credential store, or shown in the desktop app. (The CLI instead opens a local port and prints the credential to the terminal so you can connect with your own RDP client.) When the window opens you’re already signed in to the remote desktop.

Disconnect tears down the local proxy or window and ends the session. An administrator can also force-close any active session from the console, which drops it immediately.

If your grant is read-only, mutating actions are filtered (see Read-only sessions). If your access is downgraded or revoked while you’re connected, it takes effect on the live session without a reconnect.