What Is a Bastion Host?

A bastion host is a hardened, purpose-built server that sits at the edge of a private network and acts as the single controlled entry point for administrators who need to reach machines that otherwise have no direct exposure to the public internet. Instead of opening SSH or RDP on every internal server, you open it on one — the bastion — and route all remote access through that one narrow, heavily monitored door.

Why not just expose everything directly

Every internal server that listens for SSH or RDP on a public IP is a target: automated scanners probe the internet for open management ports within minutes of a server going live, and a single misconfigured firewall rule or weak credential on any one machine becomes a way in. A bastion host collapses that exposure down to one machine, which means:

• Only one host needs a public IP and an internet-facing management port at all.
• Every other server in the private network can enforce “accept SSH only from the bastion’s internal IP” — a much smaller, easier rule to audit than “accept SSH from wherever this employee happens to be.”
• Access logging, session recording, and multi-factor authentication only need to be hardened on one host instead of dozens.

How a bastion host fits into network architecture

A typical setup places the bastion in a public subnet with a route to the internet, while application and database servers live in private subnets with no public IP and no route out except through a NAT gateway for updates. An administrator connects to the bastion first, authenticates, and then hops from the bastion into the private subnet to reach the actual target machine — commonly via SSH agent forwarding or a jump-host configuration, so the private key never has to live on the bastion itself.

Modern SSH clients make this two-hop pattern nearly invisible: a ProxyJump entry in an SSH config file tells the client to tunnel automatically through the bastion to reach a private-subnet host, so connecting feels like a single ssh command even though the traffic is actually relayed through the bastion in between. This keeps the workflow simple for administrators while still enforcing that every connection to a private host passes through the bastion’s logging and access controls first — there’s no shortcut that bypasses it, since the private hosts simply don’t accept connections from anywhere else.

This is a specific application of a broader idea: minimizing the attack surface by funneling access through as few, as well-monitored, chokepoints as possible — the same philosophy behind a reverse proxy sitting in front of application servers, or a WAF filtering traffic before it reaches an app.

Bastion hosts and zero trust

Traditional bastion architecture assumes a hard perimeter: inside the private network is implicitly trusted, and the bastion is the one narrow gate through the wall. That model has been increasingly supplemented — and in some architectures replaced — by zero trust approaches, where no network location is implicitly trusted and every request is authenticated and authorized on its own merits, regardless of whether it originates inside or outside the traditional perimeter.

In practice, many organizations run both: a bastion (or a managed equivalent) as a hard boundary for interactive administrative access, layered with zero-trust identity checks for the application traffic that flows through the rest of the system. A bastion isn’t obsolete under zero trust; it just becomes one control among several rather than the sole line of defense.

Hardening a bastion host

Because a bastion is the one machine deliberately exposed to the internet, it deserves disproportionate attention:

• Minimal software. No application code, no databases, nothing beyond what’s needed for SSH access and jump-host functionality. Fewer packages mean fewer patchable vulnerabilities.
• Key-based authentication only. Password authentication should be disabled entirely; SSH keys (ideally short-lived, certificate-based ones) are the standard.
• Aggressive patching. Since it’s internet-facing, it should be first in line for OS and SSH server security updates, not last.
• Session logging. Every command run through the bastion should be logged and, ideally, recorded, so a compromised session leaves an audit trail.
• No lingering access. Access should be tied to identity and revoked immediately when someone leaves a team, not managed through shared keys that outlive individual employment.

Managed alternatives

Cloud providers increasingly offer managed bastion-equivalent services — session-manager style tools that broker short-lived access without requiring a standing SSH-listening server at all, removing the bastion itself as an attack surface. These trade some operational simplicity for meaningfully less exposure, since there’s no long-lived internet-facing SSH daemon to compromise in the first place. Whether a self-managed bastion or a managed broker is the right call usually comes down to existing infrastructure and compliance requirements more than a clear technical winner.

The takeaway

A bastion host narrows remote access to a private network down to one hardened, closely monitored entry point, instead of leaving every internal server independently exposed. It’s a perimeter-era pattern that still earns its place inside modern, zero-trust-influenced architectures — just as one control layered with identity-based checks rather than the only thing standing between the internet and your infrastructure. Whether you run one yourself or use a managed session broker, the underlying goal is the same: fewer doors, and better locks on the ones that remain.