Skip to main content

Documentation Index

Fetch the complete documentation index at: https://www.rumus.ai/docs/llms.txt

Use this file to discover all available pages before exploring further.

Most production targets aren’t reachable directly from your laptop — they sit behind a bastion (or two, or three) on a private network. Jump host chains let you describe that path once on a host record, and Rumus handles the multi-hop dance every time you connect. The order is always: Client → [Proxy] → Jump 1 → Jump 2 → … → Target.

​
Set up a chain

Jump chains live on each host record under the Host Chaining section.
1

Open the host editor

Settings → Vaults → Hosts → [your host] → scroll to Host Chaining.
2

Add a jump host

Click Add Jump Host. A searchable list of your other saved hosts appears — pick the bastion that sits between you and the target.
3

Add more hops if needed

Repeat to add more jump hosts. Drag (or use the up/down arrows) to reorder them — the order is the connection order from your machine outward to the target.
4

Save

Save the host. The next time you connect, Rumus walks the chain in order before opening the session on the target.
The connection-order display at the top of the section shows the full path so you can sanity-check it: Client → Proxy → Jump 1 → Jump 2 → Target.

​
Important: proxy is first-hop only

If you’ve configured a proxy on the target host, the proxy is only used for the first hop — your machine reaching Jump 1. Subsequent hops (Jump 1 → Jump 2 → Target) use the network of the previous bastion. That’s almost always what you want: bastions usually have direct LAN access to your private targets, so they don’t need a proxy. If a bastion needs its own proxy to reach the next hop, configure that proxy on that bastion’s host record.

​
Important: env vars and startup command run on the target

Environment variables and startup commands you set on the host record run on the target host only — not on the bastions in between. Bastions are pass-through; they don’t execute your remote shell. If you need something to happen on a bastion (e.g. set up a tunnel before continuing), give the bastion its own host record with the right startup command, and use it as a normal host directly when you need that setup.

​
Picking the right bastions

Each entry in the chain is just another saved host. That means each one carries its own auth, port, jump chain, and proxy. So:
  • A bastion that itself sits behind another bastion can have its own jump chain — no need to duplicate that path on every downstream host.
  • A bastion that uses a different SSH key than your target works fine — Rumus uses each entry’s own auth when connecting to that hop.

​
Troubleshooting

The bastion accepted you but couldn’t reach the next hop. Open the bastion directly (skip the chain) and try ssh nexthop from there manually to see the real error.
First-hop reachability is on you. Check that your network / VPN / proxy can reach the bastion, then check the bastion’s host record.
Open that bastion’s record and verify its auth method works in isolation. Saved Keychain / Saved Account references are easier to keep in sync across many records.
Practically, no — the chain is a list and Rumus walks it in order. In practice keep it as short as your network requires; every extra hop adds latency and a failure point.
Jump-chain issue we didn’t cover? Ask in the Rumus community.

​
Next steps

SSH host management

Configure the bastions you’ll chain through.

Proxy settings

Use HTTP / SOCKS5 proxies on the first hop.