TransIT AI
Sign up

Product

Jump hosts

Plenty of the time you can’t reach the gear directly — it sits behind a bastion, and you land there first before hopping to the routers. The usual workaround is nested SSH: ssh work-laptop, then ssh router from its shell. It works, but the bastion sees everything you type there, including the router’s password.

Transit reaches the same device a better way. Point a device at a jump host — SecureCRT calls it a “Firewall”, OpenSSH calls it ProxyJump — and Transit logs into the bastion with its own saved profile, opens an encrypted tunnel through it, and then connects the target end-to-end through that tunnel. The bastion carries ciphertext and nothing more.

Available in Transit 6.5.0 and later.

Set a jump host

Open a device’s Edit → Connection and pick a Jump host from the searchable list — type a device name or an IP to filter a large inventory. The default is Direct connection, and a one-click reset takes any device straight back to direct. That’s the whole setup; the device now tunnels every connection through the host you picked.

A few conveniences:

  • Chains — a jump host can itself have a jump host, up to four hops deep. Transit connects them in order, each with its own trust prompt.
  • Assign in bulk — select a stack of routers in the sidebar, Edit N devices → Jump host, and set one bastion for all of them at once.
  • Imports carry it — an ssh_config ProxyJump or a SecureCRT “Firewall Name” resolves to the matching imported or existing device automatically; anything ambiguous is left unset rather than guessed.

The jump box never sees your session

The connection to the target runs the full SSH handshake inside the tunnel, exactly as a direct connection would:

  • The target’s own host key is verified through the tunnel — first connect prompts you to trust it, and a later key change raises the same changed-key warning you’d get connecting directly. A bastion that tried to impersonate the target would fail that check, loudly.
  • The target’s credentials are used inside Transit’s own process, from your OS keyring — they’re never typed into or seen by the bastion.
  • Each hop is its own trusted connection with its own credentials, so the jump host holds no key to the device beyond it.

This is why it’s a real upgrade over nested SSH, and not just a convenience: the bastion forwards encrypted bytes and can see that you reached the target, but never your session.

It also keeps the AI’s guardrails true behind a bastion. A jumped session is, to the rest of Transit, an ordinary session on the target device — so the AI’s per-vendor permit list checks the target’s vendor, not the bastion’s. Reach a Cisco router through a Linux jump box and the AI is still held to the Cisco read-only list, with your approval click on every command.

Works everywhere a direct connection does

Jump hosts aren’t a special mode — the tunneled session behaves like any other:

  • Terminals and file transfer both. The SFTP file browser reaches jumped devices the same way a terminal does.
  • Per-hop trust. Connecting a router through a new bastion prompts you to trust the bastion first, then the router — two clear prompts, each naming its host.
  • Errors name the hop. If the bastion refuses to open the tunnel (its sshd has AllowTcpForwarding no, say), the message says so and names the jump host, instead of a vague failure on the target.

Confirming the path: run show users on a jumped Cisco device (or the equivalent) — the session’s source address is the jump host’s IP, not your workstation’s. That’s the device itself telling you the hop happened.

SSH agent forwarding

A separate, per-device option in the same Connection settings: Forward SSH agent. It’s off by default, and you should leave it off unless you specifically need it.

When on, programs running on the device you connect to — typically a bastion you work on, running git or ssh — can authenticate with your local SSH agent. Your private keys never leave your machine; the device borrows the ability to use them for the life of the session, and agents that prompt per use (like 1Password) still ask you each time.

The trade-off is real, which is why it’s opt-in and clearly warned in the dialog: while you’re connected, anyone who controls that host can sign authentications with every key your agent holds. Enable it only on hosts you trust as a workspace — and note it’s not needed for jump hosts, where each hop authenticates from Transit directly. Because it’s a security grant, it’s deliberately kept out of bulk edits and settings export; you turn it on one host at a time, on purpose.