Your servers sit in a private subnet with no public address, which is exactly where they should be. Then somebody on call at 2 a.m. needs a shell on one of them, and the question is how they get there. For about two decades the usual answer has been a bastion host.
What is a bastion host?
NIST’s glossary, quoting CNSSI 4009, defines it as “a special purpose computer on a network specifically designed and configured to withstand attacks.” In practice it is a server with a public address and almost nothing else on it. Administrators connect to it first, and it is the only machine that accepts connections from outside. Everything else only accepts traffic from the bastion.
You will also hear it called a jump host or jump box. With OpenSSH the pattern is built in: the ProxyJump option makes ssh “connect to the target host by first making an ssh connection to the specified ProxyJump host,” then carry on to the target through it.
The idea is sound. Instead of defending a dozen exposed servers, you defend one. CISA’s exposure guidance points the same way: where systems must remain internet-accessible, “use a jump host to provide secure, monitored access.”
Why a bastion helps
- One door instead of many. Firewall rules on every server collapse to “allow the bastion.”
- One place to log. If every admin connection passes through it, that is where you record who connected and when.
- Private servers stay private. The application servers need no public address at all.
The scan in the diagram above is the whole argument. From outside, you see one host.
Where a bastion falls short
It is still an internet-facing server. A bastion trades many exposed ports for one, but that one is reachable by everyone, constantly. It needs patching, key or MFA enforcement, and someone watching its logs. If it is compromised, the attacker is standing at the front door of your private network, with the access it holds.
It is a single point of failure. If the bastion is down or misconfigured, nobody can get in to fix anything, including the bastion.
Network position is doing the trusting. NIST SP 800-207 describes zero trust as assuming “no implicit trust” granted to assets or user accounts “based solely on their physical or network location.” A classic bastion works the other way round: once you are through the door, being inside the network counts for a lot. The bastion limits where traffic enters, not what an admitted user may do afterwards.
Visibility needs work. A bastion only logs what you configure it to log. The AWS documentation notes that session logging isn’t available when sessions are tunnelled through port forwarding or SSH, because the data is encrypted end to end and the service only acts as a tunnel. The same limit applies to any plain jump host: it sees a connection, not the commands inside it.
The managed alternatives
Both big clouds now sell a way to avoid running your own bastion.
AWS Systems Manager Session Manager. AWS says it provides node management “without the need to open inbound ports, maintain bastion hosts, or manage SSH keys.” Access is controlled with IAM policies, and sessions are encrypted with TLS 1.2. It covers EC2 instances and also on-premises servers and VMs.
Azure Bastion. A managed service deployed into your virtual network that gives RDP and SSH over TLS on port 443. Microsoft says your VMs “don’t need a public IP address” and “are protected from port scanning”. Session recording is a Premium SKU feature. The Basic, Standard and Premium tiers need a dedicated subnet and public IP address, and billing starts from deployment, regardless of usage.
The managed services still put something in front of your servers, but someone else patches it. Note the trade: you are tied to one cloud, and mixed estates need a second answer.
So is a bastion still enough?
It depends on what “enough” has to cover.
| Your situation | Is a bastion enough? |
|---|---|
| A handful of Linux servers, one team, one provider | Usually yes, if hardened, patched and logged |
| Many admins, contractors or vendors | Rarely; shared access and weak audit trails pile up |
| Mixed on-premises and several clouds | No; you end up running several bastions |
| Audit asks who ran what, on which server | Only with extra recording tooling |
| Regulated or high-value systems | Better combined with MFA, per-session authorisation and recording |
If you keep a bastion, treat the checklist as the minimum:
- 1Close everything elseOnly the bastion is reachable
- 2Restrict who can reach itKnown addresses, MFA
- 3Keep it smallNothing installed but access tools
- 4Log and reviewWho connected, to what
- 5Patch it firstIt is the front door
CISA’s advice backs the first of these: close or restrict access to ports that do not have a documented operational need, and require phishing-resistant MFA for all remote access.
Where SSHepherd fits
A bastion reduces your exposed ports to one. SSHepherd® goes a step further and removes the exposed port. It closes the externally exposed listening port on the server, and both the server and the administrator connect outward to a broker, which joins them only for authorised identities. That means there is no bastion to patch and nothing for a scan to find. It works over SSH, RDP, databases and file transfer, adds session monitoring, recording and a kill-switch, and can protect a server in about ten minutes without re-architecting the network. See the Linux SSH use case and the SSHepherd page. It is one answer to the admin-access question, not a replacement for all network design.
The bottom line
A bastion host is a sensible way to turn many exposed servers into one hardened door, and for a small, single-provider estate it can be enough. But it is still an internet-facing server that you patch, log and defend, and it trusts network position more than modern guidance does. If you can remove the listener altogether, with a cloud session tool or a broker, do that and retire the bastion.