How a bastion host works
A bastion host, often called a jump server, sits between untrusted networks and the systems administrators need to manage. Instead of exposing SSH or RDP on every server, the organization exposes a single hardened machine: users first connect to the bastion, authenticate there, and then hop to the internal target. Firewall rules ensure that management ports on internal servers accept connections only from the bastion.
Because it is the sole entry point, the bastion is stripped down and locked tight: minimal installed software, aggressive patching, strong authentication, and detailed logging of every connection. Modern implementations increasingly replace the raw Linux jump box with a protocol-aware gateway that brokers sessions, enforces policy and records activity rather than simply forwarding traffic.
Why it matters
Every server with a management port reachable from the outside is an attack opportunity. Concentrating access through a bastion shrinks that surface from hundreds of endpoints to one, which is far easier to patch, monitor and defend. It also gives security teams a natural choke point: anomalous logins, brute-force attempts and lateral movement all become visible in a single log stream.
The classic jump box has a weakness, though: once a user is on it, their onward actions are often opaque, and shared bastion credentials blur accountability. This is why auditors and frameworks such as PCI DSS and ISO 27001 expect not just a gateway but individual authentication, session-level auditing and controlled credential handling behind it.
Bastion hosts in practice
Teams typically start with an SSH jump host or an RDP gateway in a DMZ, enforce MFA on it and restrict internal firewall rules so nothing bypasses it. The next maturity step is replacing or augmenting the jump box with a PAM gateway that injects credentials automatically, applies just-in-time approvals and records every session, so the bastion becomes a policy enforcement point instead of a plain relay.
Monopam plays this role as a browser-based gateway: users open RDP and SSH sessions from the browser without agents or exposed credentials, while sessions are approved, recorded and tied to individual identities.