Bastion Hosts (Jump Servers)

A bastion host, also called a jump server, is a hardened server that acts as the single gateway between the Internet and your internal infrastructure. The name comes from medieval fortifications—a bastion was the tower that jutted out from castle walls, deliberately exposed so defenders could see attackers approaching from every angle.

Medieval architects understood something that still holds: the safest position isn't hiding behind walls—it's forcing everyone through your most fortified, most watched point.

The Problem: Too Many Doors

In cloud environments and corporate networks, you have servers that need remote management but shouldn't be directly accessible from the Internet. Database servers, application servers, internal services—they belong on private networks, invisible to the outside world.

But administrators need to reach them. The naive solution is giving each server a public IP address. Now attackers have dozens of doors to try. Every exposed SSH port is another lock to pick.

Bastion hosts flip this model. You expose one server—hardened, minimal, watched—and route all access through it. Internal servers accept connections only from the bastion. The attack surface collapses from many doors to one.

How the Two-Hop Architecture Works

The bastion host sits in a public subnet with an Internet-accessible IP address. Internal servers live in private subnets with no direct Internet access.

When you need to reach an internal server, you SSH to the bastion first. From there, you SSH again to the internal server using its private IP. The internal server never sees the Internet—it only sees traffic from the bastion.

Firewalls enforce this architecture rigidly. Internal servers accept SSH only from the bastion's private IP. The bastion accepts SSH only from specific trusted addresses—your office, your home network, nowhere else.

This creates a funnel. Every remote access attempt flows through one point where you can log it, monitor it, and shut it down if something looks wrong.

SSH ProxyJump: Making Two Hops Feel Like One

Modern SSH makes bastion access seamless. Rather than manually connecting twice, ProxyJump handles the routing automatically:

ssh -J bastion.example.com internal-server

One command. You connect to the bastion, the bastion connects to the internal server, and you get a direct session to internal-server. The intermediate hop is invisible.

Configure this permanently in your SSH config:

Host bastion
    HostName bastion.example.com
    User admin

Host internal-*
    ProxyJump bastion
    User admin

Now ssh internal-database automatically routes through the bastion. You never think about the hop.

Agent forwarding is an older alternative that forwards your SSH keys through the bastion:

ssh -A bastion.example.com

From the bastion, you can SSH to internal servers using your local keys. But anyone with root access on the bastion could hijack your forwarded agent. ProxyJump is safer—it doesn't expose your keys to the bastion at all.

Hardening the Bastion

The bastion is exposed on purpose, which means it needs to be bulletproof.

Minimal software. Install only what's necessary—SSH server, maybe monitoring agents. No databases. No web servers. No attack surface you don't need.

SSH keys only. Disable password authentication entirely. Without valid keys, attackers can guess passwords forever and never get in.

IP whitelisting. Configure firewalls to accept SSH only from known addresses. If your office has a static IP, that's the only IP that can reach the bastion.

Multi-factor authentication. Require a second factor beyond SSH keys—a time-based code from an authenticator app. Now attackers need your key AND your phone.

Aggressive patching. The bastion sees the Internet. Security updates must be applied immediately, not when convenient.

Comprehensive logging. Log every connection attempt, every command executed, every hop to internal servers. Alert on anything unusual.

Architecture Patterns

Single bastion works for small environments. One bastion, all access flows through it. Simple, but it's a single point of failure.

Redundant bastions solve availability. Deploy two behind a load balancer or DNS round-robin. If one dies, the other keeps working.

Per-environment bastions separate development from production. Developers get access to dev resources through the dev bastion. Production access requires the production bastion with stricter controls.

Regional bastions reduce latency in multi-region deployments. Connect to the bastion nearest the servers you need.

Ephemeral bastions minimize exposure. Spin up a bastion when needed, destroy it when done. No persistent target for attackers to probe. More complex to operate, but more secure.

Auditing: The Real Power of Single-Point Access

Routing all access through one point makes auditing trivial.

Session recording captures entire SSH sessions for playback later. Useful for compliance, troubleshooting, and investigating incidents.

Command logging tracks every command users execute. Full accountability for who did what.

Access logs show who connected, when, from where, and which internal servers they reached. The audit trail regulators ask for.

Just-in-time access integrates with approval workflows. Users request access to specific servers for specific time windows. Approved access is automatically granted and automatically revoked. No standing privileges.

Managed Bastion Services

Cloud providers offer bastion functionality without running your own servers.

AWS Systems Manager Session Manager provides bastion-like access through the AWS API. No SSH keys needed, no bastion servers to manage, all sessions logged to CloudTrail.

Azure Bastion offers browser-based SSH and RDP access to Azure VMs through the Azure portal. VMs never need public IP addresses.

Google Cloud Identity-Aware Proxy secures SSH and RDP with Google authentication integration.

These managed services trade flexibility for simplicity. They handle the hardening, patching, and high availability automatically.

When Bastion Hosts Aren't the Answer

VPN provides network-level access. Once connected, you're logically on the internal network and can reach servers directly. Different security model—broader access, different risks.

SSH certificates issue short-lived credentials signed by a certificate authority. Eliminates key distribution headaches while maintaining security.

Zero-trust architecture treats every connection as untrusted regardless of network location. No inside versus outside—every access requires strong authentication. This architectural shift makes the bastion concept less relevant.

Key Takeaways

• Bastion hosts are deliberately exposed, heavily fortified servers that funnel all remote access through a single watched point—reducing attack surface from many doors to one.
• Internal servers live on private networks and accept connections only from the bastion, never from the Internet directly.
• SSH ProxyJump makes two-hop access transparent—one command reaches internal servers through the bastion automatically.
• Hardening includes minimal software, key-only authentication, IP whitelisting, multi-factor authentication, aggressive patching, and comprehensive logging.
• Architecture scales from single bastions for small environments to redundant, per-environment, regional, or ephemeral bastions for larger deployments.
• Cloud providers offer managed bastion services (AWS Session Manager, Azure Bastion, Google IAP) that handle hardening and availability automatically.
• The real power is auditability: session recording, command logging, and just-in-time access workflows that satisfy compliance requirements.