SSH Bastion and Jump Host: How It Works, Hardening and Mesh-VPN Alternatives

Planning remote access without open SSH ports? WZ-IT builds sovereign remote-management platforms - from a hardened jump host to an identity-based mesh. Explore our remote-management platforms

An SSH bastion or jump host is a single, hardened server through which all SSH access to an internal network flows. Instead of exposing every server to the internet, only the bastion is reachable; all target systems sit behind it with no public IP. The modern, secure path through it is ProxyJump (ssh -J), not agent forwarding. This guide explains how a jump host works, how to harden it, and when a mesh VPN or ZTNA replaces the jump server.

Table of Contents

• How a Jump Host Works
• ProxyJump Instead of Agent Forwarding
• Hardening the Bastion Host
• Public Bastion or Internal Jump Host
• Bastion or Mesh VPN: When to Keep the Jump Server
• Step by Step: Base Configuration
• How We Approach This at WZ-IT
• Further Guides

How a Jump Host Works

The jump host is a deliberate choke point: every SSH connection into the internal network passes through this one server, so you only have to secure, monitor and log a single place. The internal target systems have no public IP and accept SSH only from the internal segment.

Today this is implemented with ProxyJump. The OpenSSH client first connects to the bastion and opens a TCP forward to the target through it. The actual SSH session is encrypted end to end between your machine and the target - the bastion only relays the data stream and never sees plaintext or your key. ProxyJump has been available since OpenSSH 7.3 (2016) and replaces the older, clunkier ProxyCommand (openssh.com). The current release is OpenSSH 10.3 (April 2026); since OpenSSH 10.0 (April 2025) the authentication code has been split into a separate sshd-auth binary with its own isolated address space (openssh.com/txt/release-10.0).

On the command line the -J flag is enough:

# Straight through the bastion to the internal target
ssh -J jump.example.com 10.0.10.20

# Multiple hops (each hop only needs to reach the next)
ssh -J jump1.example.com,jump2.internal 10.0.20.30

No special server-side configuration is required - the bastion just needs to reach the target and you need SSH access to the bastion. scp, rsync and sftp also work transparently over the same path.

ProxyJump Instead of Agent Forwarding

For a long time agent forwarding (ForwardAgent yes) was the go-to way to authenticate to internal hosts from the bastion. It is risky, though: while your session is open, anyone with root or file access on the jump server can reach the forwarded agent socket. The private key material cannot be read, but the attacker can make the agent sign authentication challenges and impersonate you to any server that trusts your key (man.openbsd.org: ssh_config).

ProxyJump is the clearly safer option here: instead of forwarding the agent, the client only relays stdin/stdout through the bastion. Your key stays on the workstation and the jump server never sees it. A compromised bastion therefore cannot abuse your identity.

Practical recommendation: set AllowAgentForwarding no on the bastion. Use agent forwarding only where it is genuinely needed (for example a Git push from the target system) - and even then keep it narrow and short-lived.

Hardening the Bastion Host

Because the bastion is the only entry point, it must be especially robust. The key measures:

• Key-only authentication: PasswordAuthentication no, PermitRootLogin no. Prefer ed25519 keys (the default key type in OpenSSH 10.x).
• Second factor (MFA): AuthenticationMethods publickey,keyboard-interactive combined with a PAM TOTP module. Cleaner still is binding to an identity provider via SSO and MFA - for example with Authentik or Keycloak.
• Restrict features: X11Forwarding no, PermitTunnel no, AllowTcpForwarding only where needed. For automation or transfer accounts use ForceCommand or a restricted shell so no interactive access or port forwarding is possible.
• Source IP filtering: inbound only port 22 from known networks, refined with Match Address rules.
• Logging and recording: ship sshd logs and optionally a session recording (auditd, tlog) to an external SIEM. Logs belong off-host - locally an attacker with root could alter or delete them. We use Wazuh for this; see the fundamentals in RBAC and audit for remote access.
• Short-lived certificates instead of key sprawl: an SSH CA (such as step-ca or Vault) issues short-lived user certificates. This eliminates scattered authorized_keys files and manual rotation.
• Patch and monitor: a public bastion is an attack target. Run a current OpenSSH version and back it with CVE monitoring and a regular security audit.

Public Bastion or Internal Jump Host

Not every jump host sits on the internet. Two patterns are worth distinguishing:

• Public bastion: sits in the DMZ and is the only host reachable from the internet. Maximum hardening is mandatory because it is scanned constantly.
• Internal jump host: not publicly exposed at all and reachable only over a VPN or mesh. It separates zones from one another - classically OT from IT - and forces maintenance access to take a controlled crossing. Background in OT/IT segmentation, DMZ and remote access.

Secure architectures combine both: no direct internet access to the jump host, but first into the overlay network, then through an internal, segmenting jump host to the machine.

Bastion or Mesh VPN: When to Keep the Jump Server

A bastion is simple and effective, but it remains a public target and a single point of failure. Modern zero-trust mesh VPNs like NetBird take a different approach: every participant builds the connection outbound-only, there is no open inbound port, and access is identity-based and default-deny.

Choose a bastion when you have few admins, use classic SSH and want a minimal, well-understood setup without a client rollout. Choose mesh VPN/ZTNA when you connect many distributed sites with no open ports and need granular least-privilege access plus a clean, identity-bound audit trail. NetBird's identity-aware SSH maps sessions directly to user identities and removes static key sprawl. Often the combination is ideal: the mesh as the network backend, with an internal jump host inside it for segmentation.

Step by Step: Base Configuration

1. Isolate the jump server: dedicated minimal VM/container, firewall allows inbound TCP 22 only from defined source IPs. Target systems have no public IP.

2. Harden sshd_config (on the bastion):

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowAgentForwarding no
X11Forwarding no
PermitTunnel no
AllowGroups ssh-jump
AuthenticationMethods publickey,keyboard-interactive

3. Enable MFA: wire a PAM TOTP module (for example pam_google_authenticator) into the keyboard-interactive chain. Alternatively bind to SSO/OIDC or use short-lived certificates.

4. Configure the client (~/.ssh/config on the workstation):

Host jump
    HostName jump.example.com
    User admin

Host internal-*
    ProxyJump jump
    User ops

After this you reach internal hosts directly, for example ssh internal-db01 - the hop through the bastion happens transparently, without agent forwarding.

5. Centralize logging: ship sshd logs to an external SIEM, optionally session recording via auditd/tlog.

6. Optional: certificates instead of static authorized_keys, rolled out via an SSH CA.

How We Approach This at WZ-IT

For new, distributed environments we rarely rely on a classic, internet-exposed bastion. Instead we connect sites outbound-only over an identity-based mesh (NetBird) and put an auditable browser gateway on top - no open SSH port facing the internet. Where an internal jump host makes sense as a segmentation point, we harden it consistently: key-only, MFA, ProxyJump, restricted shell and centralized logging. What this looks like in production is shown in the ABCO Water Systems case study for distributed plants in Australia. On request we handle design, build and operations end to end as part of our remote-management platforms.

This article is general information and not legal advice.

Further Guides

• What is ZTNA? - the access model beyond the choke point
• What is NetBird? - mesh VPN as a bastion replacement
• OT/IT segmentation, DMZ and remote access
• SSO and MFA for remote access
• RBAC and audit for remote access

Want to plan the right mix of bastion and mesh? Book an intro call or take a look at our remote-management platforms.