Best Practices for SSH Bastion Host Setup

In modern environments—whether on-prem, cloud, or hybrid—direct SSH access from the internet to internal servers is a risk most organisations can’t justify anymore. I’ve seen environments with hundreds of servers, all listening on port 22 from the public internet, each with slightly different SSH configs and unknown keys floating around. That’s not access control—that’s hoping nothing goes wrong.

A properly designed SSH bastion host (also known as a jump host) solves this problem by acting as a single, hardened entry point. All administrative access flows through one controlled gateway, giving you visibility, auditability, and the ability to enforce consistent security controls.

However, I’ve also seen bastion hosts become the weakest link—over-permissive, poorly logged, rarely patched, and treated as “just another server.” This article focuses on how to do it properly, based on real operational experience, not theory.

What Is an SSH Bastion Host (and What It Is Not)

A bastion host is a dedicated gateway server that accepts inbound SSH connections and then allows controlled access onward to internal systems that are otherwise unreachable from external networks.

A bastion host is not:

• A general-purpose admin workstation
• A place to run scripts, tools, or workloads
• A server with broad network access “just in case”

Its sole purpose is secure access mediation.

When implemented correctly, a bastion host:

• Dramatically reduces attack surface
• Centralises access control
• Enables strong auditing and logging
• Supports zero-trust and least-privilege principles
• Simplifies compliance and incident response

Architecture and Design Considerations (Before You Build Anything)

Most bastion problems start with poor design decisions. Before spinning up a server, think through these areas.

Network Placement and Segmentation

The bastion should live in:

• A DMZ or public subnet
• With only SSH exposed inbound
• With tightly controlled outbound access to internal hosts

It should not have unrestricted network access. Ideally, firewall rules explicitly define which internal hosts or subnets it can reach.

Redundancy and Availability

If your bastion goes down, admin access goes with it. In production environments:

• Use at least two bastion hosts
• Place them behind DNS or load balancing
• Ensure consistent configuration across both

Availability matters, but security still comes first.

Authentication Strategy

From experience, this is where most environments fall short:

• Disable password authentication
• Use SSH key-based auth only
• Strongly consider short-lived SSH certificates
• Add MFA at the bastion layer where possible

If someone compromises credentials here, they compromise everything behind it.

Step-by-Step: Building a Secure SSH Bastion Host

Step 1: Provision a Minimal, Hardened Host

Start with a clean, minimal OS image:

• Minimal Linux distribution
• No compilers, no dev tools, no unnecessary services
• Fully patched before exposure

Assign:

• Static IP or stable DNS
• Dedicated security group or firewall rules
• SSH as the only exposed service

The less running on the bastion, the smaller the attack surface.

Step 2: Harden the SSH Daemon Properly

This is not the place for defaults.

Key hardening steps in sshd_config include:

• Disable root login
• Disable password authentication
• Restrict allowed users or groups
• Disable unused forwarding features
• Limit authentication attempts
• Use modern ciphers and key types

In practice, ED25519 keys should be your baseline, with RSA only where compatibility demands it.

Also consider whether SSH agent forwarding is genuinely required—it’s convenient, but it extends trust beyond the bastion.

Step 3: Enforce Strong Key and Identity Management

Every user should:

• Have their own unique keypair
• Use passphrases on private keys
• Lose access immediately when off-boarded

In larger environments, SSH certificates are worth the effort:

• Keys become short-lived
• Revocation is simpler
• Centralised control improves auditability

Stale SSH keys are one of the most common—and dangerous—oversights I encounter during security reviews.

Step 4: Control What Users Can Reach (Not Just Who Can Log In)

A common mistake is assuming bastion security ends at login.

It doesn’t.

On the bastion host:

• Restrict which internal hosts users can connect to
• Use PermitOpen or firewall rules to limit destinations
• Separate admin users from standard operators
• Consider forced commands or restricted shells for some roles

Not everyone who needs bastion access needs access to everything.

Step 5: Logging, Auditing, and Session Visibility

If your bastion isn’t well-logged, it’s just a fancy router.

At minimum, log:

• User login events
• Source IP addresses
• Connection attempts and failures
• Session start and end times

For higher-security environments:

• Enable command logging
• Use session recording
• Forward logs to a central SIEM

When something goes wrong, the bastion logs should tell the story clearly.

Step 6: Network and Firewall Hardening

Inbound:

• Whitelist known IP ranges where possible
• Block all other ports
• Rate-limit SSH attempts

Outbound:

• Allow only SSH to internal hosts
• Block internet access unless explicitly required
• Monitor egress traffic

Remember: a compromised bastion becomes an attacker’s launchpad.

Step 7: MFA, Timeouts, and Safety Controls

Defense-in-depth matters:

• Add MFA to bastion login if supported
• Enforce idle session timeouts
• Limit concurrent sessions
• Reduce login grace times

These controls reduce risk from unattended sessions and stolen credentials.

Less Obvious (But Critical) Hardening Steps

These issues often get missed:

• Regenerate SSH host keys when cloning images
• Disable weak Diffie-Hellman moduli
• Ensure system time is synced (NTP)
• Monitor CPU and memory to detect brute-force attempts
• Protect the bastion from becoming a pivot host

Small oversights here can undermine otherwise solid designs.

Testing, Validation, and Ongoing Maintenance

A bastion host is not “set and forget.”

Regular tasks should include:

• Verifying users cannot bypass the bastion
• Testing key revocation
• Reviewing access logs
• Patching OS and OpenSSH regularly
• Reviewing firewall rules quarterly

In real environments, access requirements change constantly. Your bastion config must evolve with them.

Common Mistakes I See in the Wild

Final Thoughts: Bastion Hosts Are About Discipline, Not Complexity

A well-implemented SSH bastion host doesn’t need to be complicated—but it does need to be treated as critical security infrastructure.

When designed with least privilege, hardened SSH settings, strong identity controls, and proper logging, a bastion host significantly improves your security posture while making access easier to manage.

Done poorly, it becomes a single point of catastrophic failure.

As with most security controls, the difference lies not in the technology—but in how seriously it’s implemented and maintained.

Daniel Lutton

From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.