SSH bastion hosts: a single, hardened way into your private servers
Quick answer
A bastion host, also called a jump host, is a single, carefully hardened server that holds SSH access to a private network. You connect to it first, then hop from there to the server you actually want, so individual servers on the private network never need their own public SSH exposure at all. That leaves exactly one server's SSH surface to lock down, watch and patch, instead of every server on the network being independently exposed.
The problem it solves
If every server on a private network also has SSH open to the public internet, each one is its own independent target: its own login attempts to watch, its own sshd version to keep patched, its own configuration that can quietly drift out of line with the rest. Multiply that by however many servers you run, and you've multiplied the attack surface by the same number, even though in practice the same handful of people need access to all of them.
A bastion host inverts that. Instead of every server being reachable from the internet, only the bastion is. Every other server on the private network keeps SSH open only to internal traffic, reachable from the bastion but not from outside it. There's still exactly one door with a lock, but now there's only one door.
How the hop works
You connect to the bastion with your usual SSH client and credentials. From a session on the bastion, you then connect onward to the actual target server, which is only reachable from inside the private network the bastion sits on the edge of. Two separate SSH connections happen, one to the bastion and one from the bastion to the target, but the target server only ever sees a connection arriving from the bastion's private address, never directly from the internet.
Because the bastion is the one server with any public exposure at all, it's worth treating it differently to the servers behind it: minimal software installed, aggressive patching, key-only login, and close attention to its logs, along the same lines covered in How to improve your SSH security. A bastion that's neglected defeats the purpose, since it becomes the one weak point that grants access to everything behind it.
Making two hops feel like one
Manually SSHing into the bastion, then SSHing again from there to the target, works but gets tedious fast, and it means your private key (or at least an agent that can use it) needs to be usable from the bastion too. Two common configuration patterns avoid that:
ProxyJump
OpenSSH's -J flag, or a ProxyJump line in your SSH config, tells your own client to route the connection through the bastion automatically:
ssh -J user@bastion-ip user@target-private-ipOr set it once in ~/.ssh/config so a plain ssh target does the same thing without typing it out each time:
Host target
HostName target-private-ip
User user
ProxyJump user@bastion-ipWith ProxyJump, your client opens the connection to the target through the bastion, but the bastion itself never holds your private key. It's still a single command from your side, even though it's technically two hops.
SSH agent forwarding
Agent forwarding is the older approach: it lets a session on the bastion make use of the SSH key held by the agent running on your own machine, without ever copying the private key itself to the bastion. It works, but it's worth understanding what it grants: for as long as your forwarded session is open, anything running on the bastion under your account could, in principle, ask your agent to sign a request for another destination. ProxyJump avoids that exposure entirely, since it never involves the bastion in key handling at all, which is why it's generally the preferred pattern for a bastion setup today.
Where the bastion sits
A bastion typically sits at the edge of a private network segment, with one leg reachable from the internet and the other reachable by, or attached to, the private network holding the servers it protects. See Connecting servers over a private VLAN for how that private segment itself is put together; the bastion is what makes it practical to actually manage servers on it without opening the whole segment to the internet.