Best Practices for SSH Bastion Host Setup

In many organizations, allowing unlimited SSH access from external networks to internal servers is too risky. A bastion host (or jump box) provides a controlled, auditable gateway: all SSH access passes through this hardened node before reaching internal systems. When done correctly, bastion hosts reduce attack surface, centralize access control, and improve security. But misconfigured bastion hosts can become a single point of weakness.

This article walks through designing, deploying, and securing SSH bastion hosts thoughtfully, with practical steps, hidden configurations, and best practices to ensure strong, secure remote access.

What is a Bastion Host & Why Use One

• A bastion host is a dedicated server that acts as a gateway: external SSH clients connect to the bastion first; from there they jump to other servers in private networks.
• It enforces tighter control, logging, multi‑factor and key‑based authentication, firewall rules, etc.
• It reduces the number of servers exposed to public networks.
• Helps meet compliance, auditing, and zero trust or least‑privilege requirements.

Architecture & Design Considerations

Before building, plan these aspects:

Step‑by‑Step Setup Guide

Here’s a generalized plan for setting up a bastion host with best practices.

Step 1: Provision the Bastion Host

• Use a minimal, secure Linux distribution (or hardened image).
• Apply all current security patches.
• Assign a fixed, static IP / DNS name.
• Ensure the public interface only allows SSH (or necessary admin protocols). Use firewalls / security groups.

Step 2: Harden SSH Configuration

Edit sshd_config (commonly in /etc/ssh/sshd_config) and enforce:

• PermitRootLogin no — disable root login.
• PasswordAuthentication no — force use of public keys.
• UsePAM yes (if PAM used).
• X11Forwarding no, PermitTunnel no, GatewayPorts no, etc., unless specifically needed.
• Limit which users/groups are allowed to SSH in (e.g. AllowUsers or AllowGroups).
• Configure strong key exchange, ciphers, algorithms (e.g. prefer ED25519, ECDSA, etc.).
• Optionally disable or limit agent forwarding if it’s a risk.

Step 3: Authentication & Key Management

• Enforce public key based authentication. Each user has a keypair.
• Use certificate authority if scale requires (issuing short‑lived SSH certificates).
• Restrict private key handling: enforce passphrases where appropriate.
• Regularly audit authorized_keys, remove stale entries.

Step 4: Access Controls & Forwarding Policies

• Use ProxyJump / ProxyCommand or SSH agent to simplify usage.
• On bastion, restrict what internal hosts or subnets users can reach. Use Match blocks in SSH config to limit commands or forwarding.
• If needed, set a forced command wrapper (script) to record or constrain sessions.

Step 5: Logging, Monitoring & Session Recording

• Enable verbose SSH logging (LogLevel VERBOSE or equivalently high).
• Capture login events with timestamp, source IP, user.
• Consider setting up session recording or command‑logging wrapper so that what is done via bastion is auditable.
• Stream logs to central syslog/SIEM for retention and alerting on suspicious activity.

Step 6: Network & Firewall Hardening

• Limit incoming IPs allowed to connect to bastion (whitelisting).
• Bastion only needs egress/forwarding to internal SSH endpoints—not open to every port or service.
• Use firewall (iptables/nftables) or cloud security group to enforce ingress and egress rules.

Step 7: MFA, Timeouts & Safety Measures

• If possible, require multi‑factor authentication for bastion login (e.g. hardware token, TOTP, etc.).
• Idle session time‑outs: ClientAliveInterval / ClientAliveCountMax to disconnect idle sessions.
• Configure maximum authentication attempts (MaxAuthTries) etc.

Hidden or Less Obvious Configurations That Matter

• Regenerating host keys if cloning images to avoid identical host‑keys.
• Disabling weak DH moduli (short moduli) to avoid attack vectors.
• Using PermitTTY no / ForceCommand /usr/sbin/nologin or limited shells for some users to limit interactivity.
• Restricting or disabling X11 forwarding or port forwarding if not needed.
• Ensuring bastion host is monitored for resource usage; DoS protection if many SSH attempts.
• Clock/time‑synchronization (NTP) to make log timestamps accurate.

Example OpenSSH Bastion Config Sample (Partial)

# /etc/ssh/sshd_config on bastion host

Port 22
Protocol 2
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowGroups bastion-users admins

X11Forwarding no
PermitTunnel no
GatewayPorts no

MaxAuthTries 3
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 0

HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

LogLevel VERBOSE

# Example of restricting forwarding and destinations
Match Group bastion-users
    PermitOpen internal‑segment.example.com:22
    ForceCommand /usr/local/bin/bastion-shell-wrapper

Testing, Validation & Maintenance

• Test connecting via bastion from an external host → internal host. Use ssh -J bastion user@internal or .ssh/config settings.
• Audit that users cannot bypass bastion host.
• Simulate credentials being revoked: remove a key, verify access is cut.
• Do regular patching of bastion OS and SSH software.
• Rotate host keys if needed (especially on image‑cloned hosts).
• Review logs periodically; watch for anomalies (failed logins, attempts from unexpected IPs).

Conclusion

SSH bastion hosts are a powerful tool for centralized, secure SSH access, reducing direct exposure of internal servers and enabling strong control. But their security depends heavily on correct configuration, limited access, strong authentication, logging, and periodic maintenance.

When set up properly, a bastion host serves as a secure gateway that increases your security posture significantly without unduly burdening usability.