DMZ bastion and jump hosts — administrative access to the DMZ

The bastion is the only host that operators use to reach DMZ services. It is itself a hardened host — typically on the management VLAN or in a dedicated DMZ-admin subnet — and it is the only host authorised by the firewall to initiate administrative sessions to DMZ hosts. This lesson covers the role of the bastion, the SSH chain through it, the hardening that makes it trustworthy, and the production mistakes of allowing direct administrative access to DMZ hosts.

The DMZ exists to host services the Internet must reach. Those services need to be administered. If the administrative path bypasses the bastion, the bastion pattern is broken.

The role of the bastion

The bastion host sits between the operator and the DMZ services. Operators authenticate to the bastion; from the bastion, they authenticate to DMZ hosts. The chain:

Operator workstation → Firewall → Bastion → Firewall → DMZ host

The bastion is a hardened host — minimum installed software, key-only SSH, MFA, audit logging, restricted source IPs. It is the audit point for all administrative activity in the DMZ.

Three properties the bastion provides:

1. Single audit point. Every administrative session to every DMZ host originates from the bastion. The bastion’s shell history, session recordings, and auth log are the single audit trail.
2. Single key distribution point. Operator keys live on the bastion. Adding an operator means adding the key to one host. Removing an operator means removing the key from one host.
3. Operational tooling. Backups, configuration pulls, packet captures, and API-driven audits can run from the bastion with operator-level access, without giving every operator access to the tooling directly.

The SSH chain

The typical SSH chain from an operator to a DMZ host:

ssh operator@bastion             # operator's workstation → bastion
ssh admin@dmz-web                # from bastion → DMZ web server

The operator’s workstation never connects directly to the DMZ host. The firewall blocks direct SSH from the LAN to the DMZ (except from the bastion). The bastion is the only host that can reach DMZ hosts on TCP 22.

The SSH chain can use SSH agent forwarding, ProxyCommand, or jump-host syntax in modern OpenSSH. The bastion is the proxy.

The firewall rules:

The bastion-facing interface may be a separate physical NIC, a VLAN, or a dedicated subnet. The firewall has explicit rules permitting only the bastion to reach DMZ hosts on TCP 22.

$ ssh -J operator@bastion admin@dmz-web

operator@bastion's password:
Welcome to bastion
Last login: Mon Aug 14 03:14:01 2026 from 192.0.2.50
[admin@dmz-web ~]$

The -J flag in OpenSSH is the modern syntax for jump hosts. The connection is proxied through the bastion; the operator’s workstation only needs SSH access to the bastion, not to the DMZ host.

Where does the bastion live?

Three placements, each with different security properties:

Placement 1: Bastion on the management VLAN

The bastion has an IP on the management VLAN. Operators reach the bastion from operator workstations (also on the management VLAN). The bastion reaches DMZ hosts via firewall rules permitting management VLAN → DMZ TCP 22.

Management VLAN: bastion (10.0.0.10), operator workstations
DMZ: web, mail, DNS servers (203.0.113.0/24)
Firewall: permit mgmt VLAN → bastion 22; permit bastion → DMZ 22

This placement keeps the bastion on a highly restricted VLAN. The management VLAN has source restrictions (only operator IPs can reach the bastion).

Placement 2: Bastion in a dedicated DMZ-admin subnet

The bastion has an IP on a dedicated subnet that is reachable from the management VLAN but not from the user VLAN. The bastion reaches DMZ hosts via explicit firewall rules.

DMZ-admin subnet: bastion (172.16.0.1)
DMZ: web, mail, DNS servers (203.0.113.0/24)
Firewall: permit mgmt VLAN → bastion 22; permit bastion → DMZ 22

This placement is similar to placement 1 but uses a dedicated subnet for the bastion’s DMZ-facing interface. The bastion has two interfaces: one on the management VLAN (for operator access) and one on the DMZ-admin subnet (for DMZ host access).

Placement 3: Bastion as a hardened DMZ host

The bastion is itself in the DMZ. Operators reach the bastion via a specific firewall rule (LAN → DMZ, bastion IP, TCP 22). The bastion reaches other DMZ hosts via intra-DMZ traffic.

DMZ: bastion (203.0.113.5), web (203.0.113.10), mail (203.0.113.20), DNS (203.0.113.30)
Firewall: permit LAN jump hosts → bastion 22

This placement puts the bastion in the same broadcast domain as the DMZ hosts. The firewall rules permit only specific sources (operator jump hosts) to reach the bastion. The bastion is hardened like any other DMZ host.

Hardening the bastion

The bastion is the single point of administrative access to the DMZ. The hardening requirements are higher than for any DMZ host it administers:

• SSH key-only. Password authentication is disabled. The bastion accepts only key-based authentication. Operator keys are rotated on a schedule and revoked immediately on operator departure.
• MFA on operator login. The bastion requires MFA (TOTP, hardware token) on the operator login. The bastion is the boundary between operator credentials and DMZ host credentials.
• Restricted source IPs. The bastion accepts connections only from operator IPs (source-restricted via firewall rules or sshd_config).
• Audit logging. The bastion sends auth logs, shell history, and session recordings (if used) to a remote, immutable destination. Local logs can be wiped by an attacker.
• Minimal installed software. The bastion runs only what it needs: SSH server, audit agents, possibly tmux or screen for session persistence. No web servers, no databases, no development tools.
• Patched promptly. Critical vulnerabilities in the SSH server or the bastion OS are exploited within hours of disclosure.
• Session recording. For high-security environments, the bastion records every SSH session (using tools like tlog or sudosh). The recordings are the audit trail.

$ grep -E '^(PasswordAuthentication|PermitRootLogin|ChallengeResponseAuthentication|AllowUsers)' /etc/ssh/sshd_config

PasswordAuthentication no
PermitRootLogin no
ChallengeResponseAuthentication yes
AllowUsers operator1 operator2 operator3

Four lines of sshd_config capture the essence of bastion hardening: no passwords, no root, MFA allowed, restricted user list. The rest of the configuration is standard SSH hygiene (protocol 2 only, strong ciphers, etc.).

Bastion-to-DMZ-host authentication

The bastion authenticates to DMZ hosts using key-based SSH. The bastion holds a private key for each DMZ host (or a single bastion key that is authorised on each DMZ host). The keys are:

• Stored on the bastion only. Operators never see the bastion-to-DMZ keys. The bastion uses them transparently.
• Rotated periodically. Key rotation is a routine operational task.
• Audited. The bastion logs every SSH session to every DMZ host. The logs are sent to a remote destination.
• Restricted by command. The bastion’s key on each DMZ host may be restricted to specific commands (command="..." in authorized_keys) to limit what the bastion can do.

The “admin from anywhere” anti-pattern

A common production mistake: the operator configures the firewall to permit SSH from any source to a DMZ host. The justification is “operators need to reach it from anywhere”.

The consequences:

• The DMZ host is reachable from the Internet on TCP 22. Brute-force attacks are constant.
• The DMZ host’s SSH server is the only barrier between the Internet and administrative access to the DMZ host.
• A compromise of the DMZ host’s SSH credentials gives the attacker the same access as an operator.

The fix: the bastion is the only path to DMZ hosts. The firewall permits TCP 22 to DMZ hosts only from the bastion. Operators reach the bastion from restricted sources (operator jump hosts).

The “shared admin account” anti-pattern

Another common mistake: the operator uses a single shared admin account on DMZ hosts. The account is named admin or ops and every operator knows the password.

The consequences:

• No audit trail — every action is attributed to admin, not to the operator who performed it.
• Password rotation is impossible without coordinating with every operator.
• Removing an operator means rotating the password and distributing the new one.

The fix: per-operator accounts on the bastion (with personal keys and MFA). Per-operator or per-team accounts on DMZ hosts (with keys that are rotated and revoked as operators join and leave). Audit logs attribute actions to the operator who performed them.

A design example

For a small estate with one DMZ web server:

Management VLAN (10.0.0.0/24):
  bastion            10.0.0.10
  operator-jump-host 10.0.0.20

DMZ (203.0.113.0/24):
  web server         203.0.113.10

Firewall rules:
  LAN → bastion:22                  permit (operators reach bastion)
  LAN → DMZ:22                      deny (no direct LAN-to-DMZ SSH)
  bastion → DMZ:22                  permit (bastion reaches DMZ hosts)
  bastion → web_server:22           permit (specific)
  DMZ → LAN                         deny (default)

The operator workflow:

[operator@workstation] $ ssh operator@bastion
[bastion] $ ssh admin@web-server

The bastion is the only path. The audit trail is in the bastion’s logs and the web server’s logs.

Summary

• The bastion is the only host operators use to reach DMZ services. It is itself hardened and audited.
• The SSH chain is operator → bastion → DMZ host. The operator never connects directly to the DMZ host.
• The bastion lives on the management VLAN, in a dedicated DMZ-admin subnet, or as a hardened DMZ host with restricted source IPs.
• Hardening: key-only SSH, MFA, restricted source IPs, audit logging, minimal software, prompt patching, session recording.
• Avoid “admin from anywhere” and “shared admin account” anti-patterns.