Term — Multi-hop jump hosts

What a jump host is for

A jump host (a bastion, or ProxyJump in OpenSSH terms) is a machine you are allowed to reach, which is allowed to reach the one you actually want. Term signs in to it, asks it to open a tunnel onward, and signs in to the next hop through that tunnel. Nothing on the target has to change, and the target never needs to be exposed.

You need this when the target sits on a private network, behind a firewall that only admits one address, or inside a VPC whose only door is one gateway. It is set per host, under Advanced options.

The host editor’s Advanced options, with a Jump host row reading None (direct connection) — Empty by default — **None (direct connection)**. The note under it is the part worth reading: the terminal, SFTP *and* port forwards for this host all travel through the chain, so you do not configure them twice.

Build the route

Tap the row and the chain opens as a flow, drawn top to bottom in the order the connection is made.

The top is always This device, and the bottom is always the host you are editing. Those two are the ends; everything you add goes between them.
Tap Add jump host and pick from your saved hosts. Only eligible ones are offered — the host itself is not in the list, and neither is a mosh or telnet host, because neither protocol can carry a tunnel.
Each hop it adds is numbered in wire order, with an ✕ to take it back out.
Add a second, a third. There is no fixed limit — each one is a real login, so a long chain costs time, not correctness.

The Jump hosts sheet with no hops: This device at the top, Add jump host, then the target — Before anything is added: the two ends and nothing between them.

The Add jump host picker, showing one eligible saved host — The picker mounts in place. Here only one host qualifies — the mosh entry for the same server is excluded, because mosh cannot carry a tunnel.

The Jump hosts sheet with one numbered hop between this device and the target — One hop, numbered 1. Read it top to bottom and it is the route: this device, then that bastion, then the target.

Order is the route

The list is not a set — it is a sequence, and it has to match how the network is actually laid out. Hop 1 must be reachable from your phone, hop 2 from hop 1, and so on. Get the order wrong and the connection fails at the first hop that cannot see the next.

Long-press a hop and drag to reorder. The numbers renumber as you move it, so what you read is always what will happen.

Each hop keeps its own credentials

A hop is one of your saved hosts, so it signs in the way that host is configured — its own username, its own key or password, its own port. You are not entering anything twice, and a chain can mix a key on one hop with a password on the next.

Host keys are verified per hop. The first connection through a new bastion asks you to trust that bastion’s key, separately from the target’s.
Two-factor works on a hop too. If a bastion asks for a 6-digit code and you have stored its TOTP secret, Term answers for that hop.
A group can hold the chain, so every host in it inherits the same route instead of repeating it.

A terminal connected to the target host through the chain — Connected. The target in this example is only reachable from the bastion — the phone has no route to it at all — which is the whole point.

When a hop says no

A chain has more places to fail than a direct connection, so the failure has to say where. It names the leg rather than reporting a generic timeout.

A connection failure naming the jump tunnel and the address it could not reach — The failure names the leg: a tunnel to the target could not be opened. That is a different problem from your phone not reaching the bastion, and it points at a different fix.

For the whole story, open Show connect log (or Send diagnostics) under the buttons. It is written to be read — one line per step, hops by name.

The connect log, showing a Route diagram naming each hop in order — The log opens with the **Route**: this device, each hop by name with its user and port, then the target. Below it, each hop gets its own section.

The end of the connect log, naming the hop that refused the tunnel, with Result and Summary — And the payoff at the tail — **the bastion is named as the one that refused**, in a sentence, followed by a Result and a Summary. Nothing in it is masked: no passwords, keys or codes are ever included, but your hosts and addresses are, because a log that hides them cannot be understood.