Chapter 5

Jump Hosts & Bastions

Single entry point, audit trail, no direct prod.

Learning objectives

  • Design a bastion (jump host) architecture
  • Use ProxyJump and ProxyCommand for multi-hop access
  • Apply least-privilege access to Workshop Co. internal VMs

Why a jump host?

Workshop Co. could expose SSH on every VM to the internet — bad idea. Instead, one hardened bastion accepts connections from Marcus's home IP. All other VMs listen only on private addresses reachable through the bastion.

1

Marcus laptop → bastion.workshopco.ca:22

2

Bastion authenticates pubkey

3

Second hop → 10.20.0.5 (db VM)

4

Commands run on db; internet never touched db:22

Bastion hardening checklist

  • Minimal packages — no web app, no customer data
  • Automatic security updates enabled
  • AllowUsers marcus only (plus break-glass emergency key in sealed envelope)
  • Firewall: allow 22 from Marcus home / VPN IP only
  • Audit logging forwarded to central syslog if available

Worked example — Marcus connects to database

# One command with ProxyJump (OpenSSH 7.3+)
ssh -J marcus@bastion.workshopco.ca deploy@10.20.0.5

# Equivalent using config alias from Chapter 3
ssh workshop-db

SSH opens encrypted channel: laptop ↔ bastion ↔ db. The db server sees connection from bastion's internal IP, not Marcus's residential IP.

Agent forwarding — use sparingly

# ~/.ssh/config on laptop — generally AVOID on untrusted bastions
Host bastion
    ForwardAgent yes

Agent forwarding lets the bastion use keys from Marcus's laptop to hop further. Convenient but dangerous if bastion is compromised — attacker inherits agent access. Workshop Co. prefers ProxyJump without agent forwarding; each hop uses keys stored only where needed.

Break-glass access

Document physical console path: Proxmox IPMI or workshop site visit if bastion dies Saturday morning before class. Marcus keeps a printed runbook in the office safe.

Multiple bastions (enterprise pattern)

Larger orgs chain: internet → corp bastion → zone bastion → app server. Workshop Co. needs only one hop today. If they colocate in Calgary later, MSP might require VPN → bastion → VM — same SSH config pattern with two ProxyJump hosts comma-separated:

ProxyJump bastion.workshopco.ca,mspbastion.calgary.corp.ca

Try it yourself

Draw Workshop Co.'s access diagram: internet, router, bastion, web VM, db VM. Mark which ports are exposed on the router.

Sample diagram
  • Router: 443 → Traefik; 22 → bastion only (or VPN-only, no public 22)
  • Web VM: 80/443 internal to Traefik; SSH none on WAN
  • Db VM: 5432 from web VM only; SSH from bastion only

Check your understanding

  1. Why is the database VM safer without a public SSH port?
  2. When might agent forwarding be acceptable?
Answers
  1. Shrinks attack surface — bots and scanners cannot reach db:22; compromise requires bastion first.
  2. Trusted corp bastions with strict admin-only access and monitoring — still discouraged for small biz unless operational need is clear.