What is a bastion host? Architecture, best practices, and setup

A bastion host is a hardened server positioned at the boundary between untrusted networks and sensitive infrastructure. Administrators connect to the bastion first; the bastion forwards or brokers access to internal targets. The goal is simple: collapse many entry points into one that you can patch, monitor, and audit.

The term comes from military fortifications — a projecting structure designed to absorb attack while protecting everything behind it. In networking, the bastion is deliberately exposed so production subnets stay dark. Modern teams often graduate from a bare SSH relay to a privileged access gateway that adds policy, recording, and credential vaulting without changing the core choke-point idea.

How a bastion host works

Traffic flows in one direction: operator laptop → bastion (SSH or RDP, MFA required) → internal targets (firewall allows inbound only from the bastion subnet). Internal servers never accept connections from arbitrary corporate IP ranges. Credentials for production systems ideally never leave the private network — operators authenticate to the gateway, and the gateway injects or proxies target credentials.

Public Internet (admin workstation)
       |
       | SSH / RDP — MFA required
       v
[Bastion / Gateway] — single public IP, all sessions logged
       |
       | Internal IP only — restricted firewall rules
       v
Internal network (app servers, databases, cloud VMs)

This architecture delivers several outcomes simultaneously:

• Attack surface reduction — one IP and one port face the internet; everything else denies inbound from the public internet.
• Centralized audit trail — privileged sessions pass through one choke point, simplifying logging, alerting, and forensic replay.
• Credential isolation — target passwords and keys stay in vaults; operators use identity-bound gateway sessions.
• Single policy enforcement — MFA, IP allowlists, session timeouts, and authorization apply at the same gateway.

Reference architecture

Production bastion deployments span four layers. Layer 1 — network isolation: place the host in a DMZ or management VPC. Allow inbound SSH or RDP only from corporate IP ranges or a zero-trust connector. Outbound from the bastion is restricted to approved target subnets and ports — not the open internet.

Layer 2 — host hardening: minimal OS image, only remote-access services installed, automatic patching, no compilers or dev tools unless required. Layer 3 — authentication: disable password login, require key or certificate auth plus MFA, prohibit shared accounts. Layer 4 — audit: log every session with identity, source IP, and target; forward recordings to immutable storage and SIEM.

Hybrid and multi-site access

In multi-datacenter or hybrid cloud estates, a lightweight connector in each remote VPC or on-premises segment relays sessions from the central control plane:

Ixiea control plane (management region)
       |
       |  outbound tunnel from connector
       v
[Site connector] — deployed in target VPC or datacenter
       |
       |  SSH, RDP, database — internal network only
       v
Target asset (Linux, Windows, database, network device)

The connector initiates outbound connections to the control plane — remote sites need no inbound firewall changes for the central gateway. Assets in that site are tagged to the connector domain; policy routes sessions through the tunnel automatically.

Types of bastion implementations

• SSH bastion — Linux jump host using OpenSSH as relay; common for Linux VM administration.
• RDP bastion — Windows gateway via Remote Desktop Services for server admin.
• Privileged access gateway — multi-protocol PAM platform with vaulting, RBAC, and session recording.
• Cloud-native bastion — AWS Session Manager, Azure Bastion, GCP IAP for single-cloud teams.
• Web-based bastion — browser access with no client install; useful for zero-client environments.
• Database bastion — protocol-aware proxy for MySQL, PostgreSQL, Oracle with SQL audit.

Gateway-class platforms represent the current generation: same network isolation as a raw jump host, plus centralized credential management, compliance reporting, and command filtering under one admin console.

Bastion vs. VPN vs. zero trust

VPNs grant broad network-level access — once connected, a user can reach anything on the granted segment, creating lateral movement risk. A bastion keeps the network boundary intact and proxies only authorized sessions to specific targets. Zero trust goes further by eliminating network membership entirely and brokering per-application sessions with continuous verification — at higher implementation cost.

• Bastion/gateway — single hardened entry, session-level targets only, recording with PAM platform.
• VPN — network-level access to subnets, no session recording by default, high lateral movement risk.
• Zero trust — identity-aware per-resource access, very low lateral movement, vendor-dependent protocol support.

For most DevOps and IT operations teams, a well-configured gateway-backed bastion delivers most zero-trust benefits for privileged paths at a fraction of full ZTNA complexity.

Is a bastion still relevant in 2026?

Yes — but bare-metal OpenSSH relays are showing their limits. Manual jump hosts lack session recording, centralized credential rotation, multi-protocol support, and structured evidence exports. Configuration drift accumulates; shared keys survive offboarding.

The modern answer is a privileged access gateway as the bastion layer. Ixiea replaces the simple hop with structured access management: full session recording, credential vaulting, RBAC with time-bound grants, MFA at the gateway, web-based access without SSH clients, and multi-protocol support for SSH, RDP, databases, Kubernetes, and web assets.

The core principle — funnel all privileged access through one hardened, monitored entry — has not changed. What changed is the tooling to implement it properly.

Security best practices

• Disable password authentication — require Ed25519 or RSA 4096 key pairs; centralize key issuance through your gateway or SSH CA.
• Enforce MFA on every login — a stolen key alone should not grant production access.
• Restrict inbound by source IP — never open port 22 to 0.0.0.0/0 on a bastion.
• Minimize software footprint — no dev tools, compilers, or unnecessary services on the bastion itself.
• Enable session recording and forward logs to immutable storage — operators must not delete their own audit trail.
• Rotate credentials on a schedule — PAM platforms automate rotation so humans never hold standing root passwords.
• Set idle session timeouts — 15 to 30 minutes is typical; idle terminals are open doors.
• Alert on anomalies — new source IPs, off-hours logins, bulk transfers, privilege escalation commands.

Setting up gateway bastion access in Ixiea

Prerequisites:

• Ixiea control plane deployed and reachable from operator browsers.
• A connector server in the target network segment, reachable over SSH from the control plane for initial pairing.
• Target assets reachable from the connector internal IP.
• IdP federation configured for operator authentication.

Navigation: Admin console → Infrastructure → Connector Domains → Create. Name the domain (for example aws-singapore-vpc), assign assets, and save.

Open the domain detail view → Connectors tab → Create. Provide connector hostname, SSH port, service account, and upload the control plane public key. Run Test Connectivity — a green result confirms the outbound tunnel path.

Navigation: Admin console → Assets → select each remote asset → set Connector Domain to the domain created above. Navigation: Admin console → Access Control → Access Policy → Create — bind IdP groups, permitted accounts, recording obligations, and time windows.

Test as an operator: Workbench → select asset → Connect. Verify the session appears under Admin console → Audit → Session Ledger with replay available.

Common pitfalls

• Over-permissive security groups — lock inbound to known IPs before go-live, not after an incident.
• No session recording — a transit point without replay is not a security control.
• Shared accounts — every person must authenticate with individual identity for attributable logs.
• Neglecting the bastion itself — critical SSH and OS CVEs need patches within 24 hours.
• No break-glass procedure — cloud serial console, IPMI, or secondary bastion in another AZ.
• Forgetting connector hardening — treat site connectors with the same standards as the primary gateway.

Bastion vs. privileged access gateway

A bastion is a host. A gateway is a policy layer: identity from the IdP, JIT entitlements, protocol brokering for SSH/RDP/database/Kubernetes, command filtering, and structured evidence exports. Many teams start with a bastion and evolve when auditors ask questions the bastion cannot answer — who approved this session, which policy version applied, and can you prove the recording was not tampered with.

First setup steps

• Inventory every path that reaches production today — VPN, cloud console, emergency firewall rules, direct keys.
• Deploy the gateway in shadow mode alongside existing bastions.
• Cut over one protocol at a time; measure session evidence parity.
• Retire parallel paths only after recordings and approvals match policy.

Cloud-native bastion options

AWS Session Manager, Azure Bastion, and GCP Identity-Aware Proxy each provide managed entry without open SSH ports on targets. They work well for single-cloud estates but fragment policy when you operate hybrid infrastructure. A unified gateway like Ixiea normalizes access across cloud, on-premises, and co-location from one admin console and one audit ledger.

Teams often deploy cloud-native bastions per account or subscription, then discover auditors want correlated evidence across all environments. Exporting Session Manager logs alongside Azure Bastion RDP logs alongside on-prem syslog produces three incompatible narratives. Gateway-first design collapses that fragmentation.

Compliance and audit evidence

SOC 2 assessors ask for logical access controls on production systems. PCI-DSS requires tracking privileged users accessing cardholder data environments. ISO 27001 expects documented management of privileged access rights. A bastion without session recording fails all three — connection logs prove someone arrived, not what they did.

Gateway session exports should include identity, source IP, target asset, policy version at connect time, command transcript or screen recording, session duration, and approver identity for JIT grants. Ixiea signed export manifests pin policy versions so reviewers can trust evidence was not altered post-session.

Monitoring and alerting

Feed bastion and gateway logs to SIEM with correlation rules for off-hours access, first-time source IPs, authentication failure bursts, and privilege escalation commands. Navigation: Admin console → Audit → Integrations → configure syslog or webhook forwarding to your SIEM collector.

• Alert when production access occurs outside defined maintenance windows.
• Alert on first connection from a new country or ASN for privileged identities.
• Alert when session recording fails to start — an unrecorded session is a policy violation.
• Weekly report of denied command filter events for tuning and threat hunting.

Break-glass access

Define out-of-band access before the bastion fails during an incident. Cloud provider serial console, IPMI, iDRAC, or a secondary gateway in another availability zone each serve as break-glass paths. Document activation criteria, approvers, and post-incident review requirements.

Break-glass accounts must still produce evidence. Navigation: Admin console → Access Control → Access Policy → create a break-glass policy with enhanced recording, shorter max duration, and mandatory incident ticket reference. Never store break-glass credentials in the same vault as routine admin accounts.

Network ACL patterns

Inbound to bastion: allow SSH or RDP only from corporate egress CIDRs or zero-trust connector ranges. Deny all other inbound. Outbound from bastion: allow only target management subnets on required ports — 22, 3389, 3306, 5432 as policy permits. Deny outbound internet except for patching and telemetry.

Targets inbound: allow management protocols only from bastion or connector subnet — never from 0.0.0.0/0. Operators on laptops should not have routable paths to production CIDRs even over VPN; the gateway connector should be the only source security groups reference.

Immutable bastion infrastructure

Treat the bastion as cattle, not pet. Rebuild from golden image on schedule rather than patching in place indefinitely. Infrastructure-as-code templates for bastion and connector deployment reduce configuration drift. Version-control security group rules alongside gateway policy changes for change-management traceability.

Operator experience

Security controls fail when operators bypass them. Web Workbench access removes SSH client dependency for occasional admins. Native client proxy through the gateway preserves power-user workflows for DBAs and SREs. Both paths should enforce identical policy — recording, JIT, command filters — so there is no weak path by connection method.

Document the operator connect flow in your internal wiki: authenticate to IdP, open Workbench, select asset, choose authorized account, confirm JIT approval if required, connect. Consistency reduces shadow IT tunnels and shared-key workarounds during incidents.

Database bastion patterns

Database administration through a bastion traditionally means SSH tunnel to port 3306 — minimal SQL audit, no column-level masking. Protocol-aware database connectors log statements, mask sensitive columns, and apply SQL command filters. Navigation: Admin console → Assets → Databases → register instances with TLS and vault accounts.

Kubernetes administrative access

kubectl with embedded client certificates is a privileged path bypassing traditional bastions. Gateway Kubernetes connectors broker API access with identity attribution. Cluster-admin bindings should be JIT-gated with session evidence exported to your compliance archive.

Vendor access through the bastion layer

Third-party maintenance often arrives with VPN credentials and shared root passwords. Replace with vendor-specific IdP federation or time-bound guest accounts scoped to single assets. Enhanced recording and mandatory ticket reference on vendor policies satisfy supply-chain audit requirements.

Performance and latency considerations

Operators resist gateways that add noticeable lag. Deploy connectors in the same region as targets, size connector pools for peak concurrent sessions, and use native client proxy for high-bandwidth tasks like log tailing. Measure p95 connect latency during pilot — sub-second handshake targets keep adoption voluntary rather than mandated.

Disaster recovery for the access path

If the gateway control plane fails, production still runs but nobody administers it safely. DR plans should include secondary control plane region, replicated vault backups, and documented break-glass activation. Test failover quarterly — an untested DR plan is a narrative, not a control.

Document RTO and RPO for administrative access separately from application DR — being unable to patch or investigate during an outage extends incident duration even when customer-facing services remain up.