What a Bastion Host Is and Why It Makes SSH Access Safer - init.d
IT

# What a Bastion Host Is and Why It Makes SSH Access Safer

Alessandro Corbelli~7 min
Table of Contents

To manage a server remotely, you almost always use SSH (Secure Shell), a protocol that lets you connect to a machine and run commands from another computer, over an encrypted channel. As long as you have one or two servers, managing that access is easy. The trouble starts when they become ten, fifty, or a hundred. Opening SSH access to each of them from the internet means leaving that many doors open, and every door is something to watch. The bastion host is the most common answer to this: instead of exposing every server, you expose just one, controlled, and you pass through it.

What a bastion host is

A bastion host (often also called a jump host or jump box) is a machine that acts as the single entry point into a private network. The NIST glossary - NIST is the US agency that publishes information-security standards - defines it as a special-purpose computer on a network, specifically designed and configured to withstand attacks.

The underlying idea is simple. Nobody connects to the internal servers directly. You connect to the bastion first and, from there, reach your destination. The internal servers, for their part, accept SSH connections only from the bastion and from nowhere else. It’s the machine on the front line: the only one reachable from outside and, precisely for that reason, the one kept with the most care.

The problem: exposing every server

To see why it’s needed, the notion of attack surface helps: the set of all the points from which someone could try to get in. Every server with its SSH port open to the internet is one of those points. And it isn’t a theoretical risk: any public address receives constant automated login attempts, run by programs that try credentials one after another hoping to guess a working one.

With a single server, that’s a manageable problem. With twenty, it becomes unmanageable, for three reasons that pile up:

  • Maintenance. Every exposed machine has to be updated, watched, and kept aligned with the same rules. Keeping twenty servers perfectly in sync is far harder than keeping one.
  • Traceability. If access is possible everywhere, the record of who logged in is scattered across twenty different systems. Answering “who connected to that server last night?” turns into a small investigation.
  • Authentication. Raising the defenses - for instance by adding a second verification factor - has to be done on every machine. The same work twenty times, with twenty chances to get it wrong.

The attack surface, in short, grows with the number of open doors. Reducing that number is a defense in itself.

A single entry point: how it works

A useful comparison is the reception desk of a building with many offices. Visitors don’t walk in through any door: they go through reception, identify themselves, sign the register. Only then do they reach the right office. If someone wants to check who came in and when, they look at one register, not twenty.

The bastion host is that reception desk. It concentrates in one place the operations that would otherwise have to be repeated everywhere: verifying the identity of whoever connects, deciding who may enter and from where, logging every access. The internal servers don’t need to worry about it, because they trust that anyone reaching them has already passed the check at the border.

Why it shrinks the attack surface

That’s the main benefit: from many exposed doors you go down to one. Instead of defending twenty machines to the same standard, you defend one of them well, and the rest stay unreachable from outside.

On that one machine, then, it’s best to keep the bare minimum. A well-built bastion doesn’t host websites, databases, or other services: its only job is to pass connections through. The less software runs on a machine, the fewer possible weak spots it has. NIST makes the same point: bastion hosts, having to sit on the front line, are usually configured with as few active services as possible, the same principle behind turning off rarely used features by default, precisely to reduce their attack surface.

Access logged and verified in one place

Concentrating the entry point brings two benefits that are worth the effort on their own.

The first is traceability. If every access goes through a single host, the records (the logs) of who enters, when, and under which identity are all in one place, a requirement that lines up well with the accountability required under GDPR. By shipping them in real time to a separate collection system, the trail stays safe even if the bastion were ever compromised. The question “who connected last night?” becomes a search through the logs, not an investigation.

The second is strong authentication. A widely used way to make access safer is MFA (Multi-Factor Authentication): on top of the usual credential, a second element is required - for example a temporary code generated by an app on your phone. Even if someone stole the password, they wouldn’t get in without the second factor. With a bastion, this protection is set up once, at the entry point, instead of being configured on every server.

ProxyJump: crossing the bastion the right way

For years the “jump” through the bastion was done by hand: you connected to the bastion and from there ran a second SSH command toward the internal server. It works, but it’s clumsy and it isn’t the better choice from a security standpoint, because the connection to the final destination is created and lives on the most exposed machine.

Since version 7.3, OpenSSH (the most widely used SSH implementation) offers a dedicated option, ProxyJump, with its -J flag. The release notes describe it plainly: it adds a ProxyJump option and the -J command to simplify indirect access through one or more bastions, or “jump hosts.” From the user’s side, the jump becomes an invisible detail:

Terminal window
# One command: the hop through the bastion is automatic
ssh -J bastion.example.com internal-server.lan

Better still, you can save the configuration in your computer’s ~/.ssh/config file and forget about it:

Host internal-server
HostName 10.0.5.20
ProxyJump bastion.example.com

The difference isn’t only convenience. With ProxyJump the bastion simply forwards the data toward the destination, while the SSH connection stays encrypted end to end between your computer and the internal server. In practice the bastion passes along data it can’t read. What to avoid, instead, is the agent forwarding shortcut, which would make your access key usable by the bastion itself: the official documentation advises using it with caution, which is why it’s turned off by default.

Where it fits in an architecture

A bastion only works if the network is organized around it. The typical setup relies on segmentation: the bastion lives in an exposed, controlled zone (often called a DMZ or public subnet), while the actual servers sit in a private zone that isn’t reachable directly from the internet. A firewall enforces the rule that makes everything else true: toward those servers, SSH connections are accepted only if they come from the bastion.

Without that separation, the bastion would be a reinforced door next to an open window: anyone could bypass it by connecting straight to the servers. With segmentation, the only route inward runs through the controlled border.

There’s a trade-off to keep in mind: by concentrating everything in one place, that place becomes critical. If the bastion is misconfigured or stops working, access to everything is blocked. That’s why it has to be kept minimal, updated, and watched with particular care. A bastion isn’t the only way to solve the problem - a VPN, for example, tackles the same need from another angle - but it remains one of the simplest and most common.

In short

A bastion host is a funnel: it forces every access through a single point, where you concentrate the defenses it would be absurd to replicate everywhere. It shrinks the attack surface because, instead of many exposed doors, it leaves one well-protected door; it makes access traceable because it gathers it into a single register; and it lets you raise authentication once and for all rather than machine by machine. Crossing it with ProxyJump also makes it convenient and safe to use. It isn’t a magic solution, and it needs a segmented network to really work, but it’s one of the sturdiest ways to bring order to access that has grown out of control.

Sources

Tux versione Gandalf, mascotte del blog init.d

init.d is the team led by Alessandro Corbelli, a Linux systems administrator and backend developer with over twenty years of experience. He designs and runs cloud infrastructure (Google Cloud, AWS, Azure), server farms and high-availability architectures, and builds custom software in Laravel/PHP and Vue - from the Take2Me food delivery platform to our clients’ management tools. On this blog we share technical notes on Linux, system administration, development, DevOps and e-commerce.


More Posts