Reference Guide
What is a bastion host?
A plain-language guide to bastion hosts and jump servers — what they are, how the architecture works, how they compare to VPNs and zero trust, and the mistakes that undo them.
Definition
A bastion host is a specially hardened server that sits at the boundary between a public network — usually the internet — and a private internal network. It is the single authorised entry point for remote administrative access to systems behind it.
The name is borrowed from military fortification. A bastion is the projecting part of a defensive wall: deliberately exposed, deliberately reinforced, and built so that everything approaching it can be seen and answered. A bastion host plays the same role in a network. It is the one machine you allow the outside world to reach, so it is the one machine you fortify and watch above all others.
You will also hear jump server, jump host, and secure access server. In practice these terms overlap. "Jump server" describes the function — connect here, then jump onward. "Bastion host" emphasises the security posture: minimal, hardened, monitored. A jump box with a shared password and no logging is technically a jump server. It is not a bastion host.
The core idea in one sentence: instead of defending hundreds of reachable systems, you make only one system reachable and defend it properly.
How the traffic actually flows
Internal systems are configured to accept administrative connections only from the bastion's private address. From the public internet they are unreachable — not merely firewalled off, but with no route in at all.
- Authenticate
- Authorise
- Broker
- Record
Direct connections from the internet are refused. Internal hosts accept traffic only from the bastion's private address.
The four layers of a real bastion
A hardened gateway is not one control. It is four layers that each fail differently, so that no single mistake exposes the network behind it.
Network Isolation
The host lives in a DMZ subnet with tightly restricted inbound and outbound traffic. Only authorised source addresses may reach SSH or RDP. All other traffic is blocked by default rather than permitted by oversight.
Host Hardening
A minimal software footprint with only the services the gateway genuinely needs. Automatic operating system updates are enabled and vulnerability scans run on a schedule, not on request.
Authentication
Password authentication is disabled outright. Key pairs — RSA 4096-bit or Ed25519 — are mandatory, multi-factor authentication is required at every login, and every user has an individual account. No shared logins.
Audit & Monitoring
Complete session logging with timestamp, user identity, source address, and target host. Session recordings — keystroke logs and screen replay — are held in tamper-resistant storage, with real-time alerting on anomalous behaviour.
What you gain
- A reduced attack surface. One address and one port face outward instead of an inventory of exposed management interfaces nobody has fully enumerated.
- A centralised audit trail. Every privileged action passes through a single monitored chokepoint, so "who did that, and when?" has one authoritative answer.
- Credential isolation. Internal passwords never leave the private network. With credential vaulting, operators never see them at all.
- Uniform policy enforcement. MFA, source-address allowlisting, session timeouts, and approval workflow are applied in one place, consistently, rather than configured per host and drifting apart.
- Faster incident response. When something goes wrong, the recording of what happened already exists — it does not have to be reconstructed from partial logs.
Types of bastion host
Which shape fits depends on what you administer, how many teams need access, and how much evidence you are required to produce.
| Type | Typical use case |
|---|---|
| SSH bastion | Linux and Unix server administration |
| RDP bastion | Windows server and desktop administration |
| PAM platform | Enterprise environments with multiple protocols, teams, and audit obligations |
| Cloud-native bastion | Single-provider cloud estates using the provider's own session service |
| Web-based bastion | Zero-client, browser-accessible gateways for field staff, partners, and vendors |
| Database bastion | DBA teams needing protocol-aware, statement-level session audit |
Bastion vs VPN vs zero trust
These are frequently framed as competitors. They are better understood as different answers to different questions — and many organisations run more than one.
| Approach | What it grants | Lateral movement risk | Session recording |
|---|---|---|---|
| Bastion host | A specific brokered session to a specific target through a hardened gateway | Low — no broad network access is granted | Native to the platform |
| VPN | Broad subnet-level network access once connected | Higher — a compromised client sits inside the network | Requires additional tooling |
| Zero Trust (ZTNA) | Per-application sessions brokered on continuous identity verification, with no network-level access at all | Lowest | Varies by implementation |
Zero trust is the strongest model on paper and the most demanding to implement — it typically means re-architecting how applications are published and identity is evaluated. For most operations and infrastructure teams, a PAM-backed bastion is the practical balance between security gained and complexity taken on. It can also be a sensible staging post on the way to a broader zero trust programme.
From SSH jump box to privileged access platform
The original bastion host was a single hardened machine and a well-maintained set of SSH configuration files. That still works for a small estate with a handful of administrators. It stops working when the questions get harder.
Modern privileged access management platforms — including open-source implementations such as JumpServer, released under GPL-3.0 — extend the same principle with capabilities a hand-built jump box cannot reasonably provide:
- Full session recording with tamper-resistant replay across every protocol.
- Centralised credential vaulting, so users never handle production passwords.
- Role-based authorisation with time-bound, expiring access grants.
- Multi-protocol brokering — SSH, RDP, VNC, MySQL, PostgreSQL, Oracle, Kubernetes and more.
- Browser-based access that requires no client software on the operator's device.
- Compliance reporting aligned to frameworks such as SOC 2, ISO 27001, and PCI-DSS.
Hybrid and multi-datacenter estates add another problem: how do you bring a remote segment under one policy without opening it up? The established answer is a lightweight relay deployed inside the remote datacenter or cloud VPC that authenticates outbound to the central control plane over an SSH tunnel. No inbound firewall change is required, and no site-to-site VPN needs to exist for privileged access to be governed centrally.
Do These
Eight practices that carry most of the weight.
- Disable password authentication and require key pairs.
- Enforce MFA on every login — TOTP or hardware tokens, no exceptions for convenience.
- Restrict inbound access by source address to known office ranges and VPN egress nodes.
- Minimise the software footprint; a bastion is not a utility server.
- Enable session recording with immutable storage — object-lock buckets or a write-once SIEM tier.
- Rotate credentials on a schedule that runs automatically rather than when someone remembers.
- Set session timeouts — 15 to 30 minutes of idle time is a common, defensible baseline.
- Monitor for anomalies: unfamiliar source addresses, out-of-hours access, and failed login clusters.
Avoid These
Six failures we find over and over.
Opening port 22 to 0.0.0.0/0 with the intention of restricting it later. The restriction rarely arrives; the scanners always do.
Running without session recording. Access control tells you who could act. Only recording tells you what they did.
Shared accounts. A login used by four people is attributable to none of them, and cannot be revoked for one of them.
Neglecting patching and scanning on the one host you have deliberately exposed to the internet.
No break-glass procedure. When the bastion is down and nobody has a tested alternative, the emergency workaround becomes the new vulnerability.
Unhardened relay servers in multi-site deployments — a carefully built gateway undermined by a forgotten satellite.
Does the bastion host still matter in 2026?
Yes — though the tooling has moved on considerably. The core principle is unchanged: funnel all privileged access through a single hardened entry point that is monitored properly. What has changed is what sits at that point.
Organisations are steadily migrating from bare-metal SSH jump hosts to privileged access management platforms, because the newer generation delivers session recording, centralised credential management, multi-protocol support, and compliance-ready audit trails without requiring the network itself to be redesigned. The architecture stays the same. The evidence it produces gets substantially better.
Where Vaultris fits. We assess the access paths you already have, design the gateway architecture around them, deploy and harden it against a documented baseline, and sustain it — patching, rotation, access review, and audit evidence — so the control keeps holding after the project closes.
Next Step
How many administrative doors does your network have?
Most organisations are surprised by the answer. A Vaultris access path assessment produces it in writing.