What is a jump host? (And how to use one without collecting keys on it)

A jump host is a hardened intermediary server that acts as the single, audited entry point into a private network. The servers you actually care about — databases, app servers, build machines — have no public address at all; the only way to reach them over SSH is to go through the jump host. You connect to it from the outside, and from there your connection continues inward to the machine you wanted.

That's the definition. The design question that follows — how to pass through it without scattering credentials along the way — is where most setups go wrong, and it's what the rest of this page is about. If you already know the concept and just want the commands, the ProxyJump setup guide is the how-to; this page is the what and the why.

Jump host, bastion, jump box, gateway: one idea, four names

The terminology is an archaeology of the same pattern. Bastion host is the oldest term, borrowed from fortification — the strongpoint built to face the attack. Gateway emphasizes the network role: the machine that connects two networks that otherwise don't touch. Jump host and jump box describe what operators experience — you "jump" through it to get somewhere else. Cloud vendors' managed offerings are the same idea again, productized.

There are shades of usage — "bastion" tends to imply deliberate hardening, "jump host" sometimes just means "the box I hop through" — but in practice the terms are interchangeable. If a machine's job is to be the one exposed SSH door in front of private infrastructure, it's a jump host, whatever the runbook calls it.

Why funnel everyone through one machine

The logic is concentration. Exposing twenty servers to the internet means twenty attack surfaces to patch, twenty sshd configs to keep tight, twenty places to watch for brute-force noise. Put a jump host in front and the arithmetic changes:

• One machine to harden. Minimal packages, current patches, strict sshd config — affordable when it's one box instead of a fleet.
• One place for strong authentication. Enforce keys-only, MFA, or short-lived certificates at the door, once, instead of wiring it into every internal server.
• One choke point to audit. Every administrative session crosses the same threshold, so "who connected, when, from where" has a single authoritative answer — more on that below.
• A smaller blast radius. Internal machines can drop their public exposure entirely and accept SSH only from the jump host's address.

The trade is obvious and accepted: the jump host becomes the most attractive target on your network. The entire design rests on it holding access without holding secrets — which is exactly the property careless usage destroys.

How traffic actually flows through one

The modern mechanism is OpenSSH's ProxyJump (ssh -J), and the detail that matters is where the second connection terminates. Your client connects to the jump host, authenticates, and then uses that connection purely as a transport — inside it, your client opens a second, end-to-end encrypted SSH connection directly to the internal machine. Authentication to the target happens from your laptop; the session's encryption is negotiated between your laptop and the target.

The jump host shuttles ciphertext. It never sees your private key, never holds your session's plaintext, and cannot read what you type on the inner connection. Even if the jump host were fully compromised, the attacker could observe that a connection passed through — not what happened inside it.

Contrast the old pattern this replaced: SSH to the jump host, land in a shell on it, then run ssh again from there to the target. In that world the jump host is a full participant — the inner session is decrypted and re-encrypted on the box, so anything on it can read your session, and you need credentials for the target available on the jump host to make the second hop at all. That one requirement is the root of most jump-host security failures.

The minimal setup

A common misconception is that a jump host needs special software. It doesn't — it's a role, not a product. The bastion side needs an ordinary sshd and user accounts (hardened, patched, keys-only — but ordinary). All the routing intelligence lives client-side, in one line of ~/.ssh/config:

Host bastion
    HostName bastion.example.com
    User jump

Host db
    HostName 10.0.0.9
    User deploy
    ProxyJump bastion

Now ssh db transparently routes through the bastion to a private address your laptop can't even reach directly. Chains (ProxyJump hop1,hop2) and the full set of options are in the setup guide.

A minimal hardening checklist

The bastion has to earn the trust the design places in it. None of this is exotic — the point of the pattern is that it only has to be done on one machine:

• Keys only, no passwords. PasswordAuthentication no and PermitRootLogin no in sshd_config. An internet-facing sshd gets password-guessed around the clock; this ends that class of attack outright.
• Nothing on the box but the door. No app code, no databases, no developer tooling — the fewer packages installed, the less to patch and the less an intruder finds to work with.
• Patch on a schedule. Unattended security updates for the OS, and a standing habit of keeping sshd itself current — this is the one host where "we'll update next quarter" isn't acceptable.
• Throttle the noise. fail2ban, or sshd's own MaxStartups limits, so brute-force attempts stay background static instead of becoming load.
• Log off the box. Ship auth logs somewhere the bastion can't edit — a compromised gateway shouldn't get to rewrite its own history. Whether to go further and record sessions is its own question, covered below.

The two mistakes that undo the design

Both come from the old land-in-a-shell habit, and both put your identity on the one machine most likely to be attacked.

Storing private keys on the jump host. If making the second hop requires a key sitting in ~/.ssh on the bastion, then everyone's keys accumulate on the single most exposed machine in the network — and a compromise of that one box yields credentials to everything behind it. The jump host was supposed to contain a breach; a key collection turns it into the breach's distribution point. With ProxyJump there is simply no reason for any private key to exist there.

Agent forwarding through it (ssh -A). Subtler, because the key itself stays home — but forwarding exposes your agent's socket on the jump host, and anyone with root there can use your identity for as long as you're connected. On a shared, internet-facing gateway, that's precisely the wrong place to offer it. The full argument is in agent forwarding is convenient and dangerous; the short version is that ProxyJump makes forwarding unnecessary for the hop itself.

When you don't need one

A jump host earns its keep when there's a private network behind it and more than a couple of people in front of it. If you run a single VPS with a public address, adding a bastion adds a hop and a maintenance burden without meaningfully reducing exposure — tighten that one sshd instead. And modern mesh VPNs and overlay networks solve an overlapping problem by putting your laptop on the private network, so every internal machine is reachable directly over an encrypted mesh. That can replace a jump host for connectivity — though teams often keep one anyway, precisely because a single audited SSH door is easier to reason about (and to show an auditor) than "every device can reach everything."

The same honest comparison applies to zero-trust access products — identity-aware proxies that put SSO, device checks and per-request policy in front of every connection. They solve the jump host's problem with more machinery and stronger guarantees, and at some combination of headcount and compliance pressure that machinery pays for itself. Below that line, a jump host is the version of the same idea you can build in an afternoon with stock OpenSSH — no new vendor, no new agent on every laptop, and every property of it inspectable in two config files.

The audit dividend

Concentration cuts both ways, and the second edge is useful: because every session crosses the jump host, it's the one place with a complete view of who came in, when, and from where. That makes the bastion the natural anchor for session auditing — and also the place where doing it wrong (shared accounts, keystroke capture, recordings stored on the same box) hurts most. The architectures and traps get a full treatment in recording and auditing SSH sessions on a bastion.

Where Termalin fits

Termalin treats the jump host as part of a saved server's configuration: attach a bastion to a host, and every connection to that internal machine routes through it automatically — keys stay on your machine, nothing is copied to the gateway, no agent socket is exposed there, and each hop's identity is verified on first connect with a loud warning if a fingerprint ever changes. For the audit side, sessions can be recorded client-side — output only, never keystrokes — with an audit log of who connected where and when, which pairs naturally with whatever recording the bastion itself does. The Free tier has no host limits — download it and put the private network one click away.

---

Termalin is a free, cross-platform SSH client with jump-host support, output-only session recording and a key manager — download it, or see how it handles your keys safely.