Bastions & jump hosts

Availability All editions, Community included.

Many targets aren’t reachable directly — they sit in a private subnet behind a bastion (jump host). Tessera dials the target through the bastion, injecting the right credential at each hop, so the user never holds a key to either machine.

If the question is whether to keep the bastion at all rather than how to reach through one, see bastion host and jump server alternative.

How it works

When a target has a bastion configured, the controller:

1. Opens an SSH connection to the bastion using the bastion’s stored credential.
2. From the bastion, opens a channel to the target’s host and port.
3. Completes the connection to the target over that channel, injecting the target’s credential.

Both hops are brokered — neither credential ever leaves the controller — and host keys are pinned (TOFU) independently for the bastion and the target.

Configure a bastion

On a target’s Connection settings, set the Bastion. You can either:

• Point at an existing SSH target — reuse another target as the jump host, along with its stored credential and pinned host key. This is the recommended pattern.
• Specify an inline host — a bastion host/port/credential just for this target.

Define the bastion once

Create the jump host as its own SSH target, then reference it by name from every private target behind it. Rotating the bastion credential in one place applies to every connection that hops through it.

In bulk import

The import format lets you declare a bastion once and reference it from many targets by name, so a large private fleet can be onboarded in a single YAML document without repeating jump-host details.

Audit

Connections through a bastion are audited like any other session — the log records the target you reached; the hop through the bastion is part of the brokered path, not a separate login.