Post cover image

September 3, 2026

Demystifying SSH via Bastion Host: Architecture, Key Forwarding, and Best Practices

In modern cloud engineering, exposing database clusters or backend microservices directly to the public internet is a major security…

By Techie Crow

4 min read

In modern cloud engineering, exposing database clusters or backend microservices directly to the public internet is a major security vulnerability. Zero Trust security frameworks insist that production instances reside within highly isolated private subnets with no public IP addresses assigned.

However, site reliability engineers (SREs) and database administrators still require secure remote access for troubleshooting, system maintenance, and infrastructure operations. This creates a classic architectural dilemma: How do you grant administrative access to air-gapped private instances without compromising network isolation?

The standard industry solution is the SSH Bastion Host (commonly known as a jump server). In this comprehensive article, we will analyze how SSH via a bastion host operates under the hood, compare key connection paradigms, configure seamless SSH clients, and explore modern zero-trust evolutions.

1. What is a Bastion Host?

None

A bastion host is a special-purpose server located in a public subnet or Demilitarized Zone (DMZ). It acts as the single fortified entry point for administrative traffic entering an internal private network (such as an AWS VPC or GCP VPC Network).

Rather than leaving port 22 open across dozens of internal application nodes, security teams enforce a strict firewall policy: all private subnets reject inbound traffic except SSH connections originating from the Bastion Host's security group or internal IP address.

Key Architectural Properties of a Bastion Host:

Hardened OS Profile: Stripped of unnecessary daemons, services, and compilers to minimize exploit surfaces.

Strict Access Control: Enforces Public Key Authentication, Multi-Factor Authentication (MFA), and session timeouts.

Centralized Audit Logging: Records session metadata, shell execution history, and connection duration for compliance.

2. Under the Hood: How the Connection Flow Works

To establish a session on an internal server (e.g., 10.0.1.45) via a public bastion (e.g., 203.0.113.10), two distinct hops are executed seamlessly under the hood:

  1. Hop 1 (Client to Bastion): The local client initiates an encrypted SSH session over the public internet to the Bastion host's public IP address using SSH Key Pair credentials.
  2. Hop 2 (Bastion to Target Instance): Once authenticated, traffic is routed through an internal virtual channel to the target server's private IP address within the local network.
None

3. Connection Paradigms: ProxyJump vs. Agent Forwarding

Historically, engineers used SSH Agent Forwarding (ssh -A) or manual multi-stage logins to hop through bastions. Modern OpenSSH releases introduced superior alternatives that enhance security and simplify workflows.

Method A: Modern ProxyJump (-J Flag) — The Recommended Standard

       [ Public Internet ]
                │
                │ SSH (Port 22)
                ▼
┌──────────────────────────────────────────────┐
│  VPC / NETWORK BOUNDARY                      │
│                                              │
│  ┌────────────────────────────────────────┐  │
│  │  PUBLIC SUBNET                         │  │
│  │                                        │  │
│  │   ┌───────────────────────────┐        │  │
│  │   │     Bastion Host          │        │  │
│  │   │    (Jump Server)          │        │  │
│  │   │  • Has Public IP          │        │  │
│  │   │  • Internet Facing        │        │  │
│  │   └───┬───────────────────────┘        │  │
│  └───────┼────────────────────────────────┘  │
│          │                                   │
│          │ Internal SSH (Port 22)            │
│          ▼                                   │
│  ┌────────────────────────────────────────┐  │
│  │  PRIVATE SUBNET                        │  │
│  │                                        │  │
│  │   ┌───────────────┐   ┌───────────────┐│  │
│  │   │  App Server   │   │Database Server││  │
│  │   │ • No Public IP│   │• No Public IP ││  │
│  │   └───────────────┘   └───────────────┘│  │
│  └────────────────────────────────────────┘  │
└──────────────────────────────────────────────┘

Introduced in OpenSSH 7.3, ProxyJump creates a TCP forwarding channel through the bastion directly to the target server. The client establishes an end-to-end encrypted SSH session with the target server. Crucially, the bastion host never sees unencrypted traffic or your private key; it merely acts as a layer-4 socket forwarder.

# Syntax: ssh -J <bastion-user>@<bastion-ip> <target-user>@<target-private-ip>
ssh -J ubuntu@203.0.113.10 ubuntu@10.0.1.45

Method B: SSH Agent Forwarding (-A) — Legacy & Risks

Agent Forwarding allows the bastion server to leverage your local ssh-agent socket to authenticate against the target server. However, if an attacker gains root privileges on a compromised bastion host, they can hijack your forwarded socket to access other internal instances while your session is active.

⚠️ Security Rule: Prefer ProxyJump over Agent Forwarding whenever possible. ProxyJump keeps private key authentication strictly between your local laptop and the target host.

4. Advanced Client Automation via ~/.ssh/config

Memorizing long IP addresses and multi-step flags reduces developer productivity. By customizing your local ~/.ssh/config file, you can automate bastion routing transparently:

# --- Bastion Host Configuration ---
Host bastion
    HostName 203.0.113.10
    User ubuntu
    IdentityFile ~/.ssh/id_ed25519_bastion
    Port 22

# --- Wildcard Private Subnet Routing ---
Host 10.0.*
    User ubuntu
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519_internal
    ServerAliveInterval 60
  • Host bastion: Creates a named alias bastion for the jump server. Running ssh bastion automatically applies all parameters declared in this block.
  • HostName 203.0.113.10: Specifies the real network address (IPv4, IPv6, or fully qualified domain name) of the publicly accessible bastion instance.
  • User ubuntu: Defines the remote username to authenticate as on the bastion host.
  • IdentityFile ~/.ssh/id_ed25519_bastion: Specifies the path to the local SSH private key used exclusively for authenticating with the bastion. Ed25519 is utilized here as a modern, secure elliptic-curve signature algorithm.
  • Port 22: Explicitly declares the standard listening port for SSH daemon traffic on the bastion host.
  • Host 10.0.*: A wildcard pattern matching any SSH command targeting an IP address or hostname starting with 10.0. (e.g., ssh 10.0.1.45 or ssh 10.0.50.12).
  • User ubuntu: Specifies the remote system user for the target instances inside the private subnet.
  • ProxyJump bastion: The key directive that automates multi-hop routing. When invoked:
  1. Your SSH client looks up the alias bastion defined in Section 1.
  2. It opens an SSH session to 203.0.113.10.
  3. It requests the bastion host to establish a TCP socket forward (using nc-like stdio forwarding under the hood) directly to the target private IP (10.0.x.x).
  4. An end-to-end SSH session is encrypted directly between your local laptop and the target host across this TCP channel. The bastion never sees the target server's unencrypted data or private key payload.
  • IdentityFile ~/.ssh/id_ed25519_internal: Defines the private key corresponding to the public key authorized on the internal private instances. Key separation ensures that compromising the bastion key does not grant direct access to internal resources.
  • ServerAliveInterval 60: Sends an encrypted keepalive null packet through the tunnel every 60 seconds. This prevents intermediate NAT gateways, cloud firewalls, or stateful security groups from dropping inactive connections due to idle TCP timeouts.

Operational Workflow Comparison

Without ~/.ssh/config (Manual Execution):

# Complex, verbose command required every time:
ssh -i ~/.ssh/id_ed25519_internal -J ubuntu@203.0.113.10:22 ubuntu@10.0.1.45

With ~/.ssh/config (Automated Execution):

# Simple single-line command:
ssh 10.0.1.45

Conclusion

SSH Bastion hosts are a cornerstone of network defense-in-depth architecture. By consolidating administrative access points, enforcing key isolation via ProxyJump, and leveraging automated client configurations, engineering teams can maintain a rigorous security posture without hindering daily operational workflows.