SSH Bastion Host (Jump Server) Configuration Guide: A Secure Gateway for Linux Systems – ITFROMZERO

Table of Contents

Why You Need a Bastion Host Immediately

When I first started my career, I managed a cluster of 20 servers running services for clients. To make it easier to SSH from home, I opened port 22 publicly on all machines. As a result, at 2 AM one night, the system alarms went off. Checking the logs, I was horrified to find over 50,000 brute-force requests hitting the servers in just one hour. One server had been compromised because a developer set a password that was too simple.

After that shock, I realized that exposing internal servers directly to the Internet is a fatal mistake. That’s why I switched to using a Bastion Host (also known as a Jump Server). Instead of leaving 20 doors wide open, I opened only a single entrance. This entrance is heavily reinforced, and every action passing through it is strictly monitored.

What Exactly is a Bastion Host?

Imagine a Bastion Host like a guard post at the gate of a luxury apartment complex. You cannot just barge directly into a resident’s apartment. You are required to pass through the guard post, present your ID, and have the guard record your entry and exit times.

In IT infrastructure, a Bastion Host is a server located in the perimeter (Public Subnet). It acts as the sole transit point for accessing internal servers (Private Subnet). At this point, internal servers close port 22 to the world and only accept connections from the Bastion Host’s IP address.

This model provides three core benefits:

Reduced Attack Surface: Hackers only have one target to attack instead of dozens of servers as before.
Centralized Management: All security configurations and SSH Keys only need to be managed in one place.
Accurate Audit Logs: You know exactly who accessed which server, at what time, and what commands they typed.

Practice: Configuring a Professional Bastion Host

Step 1: Hardening the Bastion Host

Since this is the final checkpoint, if the Bastion Host is compromised, hackers will have the keys to the entire system. Therefore, securing the Bastion itself is the top priority.

Completely disable password login and only use SSH Keys for authentication. Open the /etc/ssh/sshd_config file and edit it as follows:

# Disable password authentication
PasswordAuthentication no
PubkeyAuthentication yes

# Allow only specific users
AllowUsers admin-devops

# Change SSH port to reduce 90% of junk logs from bot scans
Port 2222

Then, restart the service: sudo systemctl restart ssh.

Step 2: Using SSH ProxyJump (The Standard Way)

Many people have the habit of SSHing into the Bastion and then copying their Private Key there to SSH further into internal machines. Never do this! If the Bastion is hacked, all your Private Keys fall into the hands of attackers.

The safest way is to use the ProxyJump feature. On your personal machine, configure the ~/.ssh/config file:

# Bastion Host configuration
Host bastion
    HostName 1.2.3.4
    User admin-devops
    Port 2222
    IdentityFile ~/.ssh/id_rsa_bastion

# Internal Server configuration
Host server-app-1
    HostName 10.0.1.50
    User deploy-user
    IdentityFile ~/.ssh/id_rsa_internal
    ProxyJump bastion

Now, you just need to type ssh server-app-1. The SSH client will automatically connect through the Bastion. No Private Keys are stored on the Jump Server.

Step 3: Audit Logging of All Sessions

This is a fantastic feature for monitoring. I often use the script command to record everything happening on the terminal. First, create a log directory on the Bastion:

sudo mkdir -p /var/log/bastion
sudo chmod 733 /var/log/bastion

Next, create the /usr/local/bin/bastion-session.sh script to automatically trigger when someone connects:

#!/bin/bash
# Define log file path with timestamp
LOG_FILE="/var/log/bastion/session_${USER}_$(date +%Y%m%d_%H%M%S).log"
echo "--- Welcome! Your session is being recorded ---"
/usr/bin/script -q -f $LOG_FILE
exit

Grant execution permissions: sudo chmod +x /usr/local/bin/bastion-session.sh. When a user logs in, every command and output will be saved to /var/log/bastion/ for you to check at any time.

Step 4: Restricting Permissions to the Maximum

In reality, users don’t need permission to execute commands on the Bastion itself. You can restrict them to only being allowed to use SSH tunnels. In /etc/ssh/sshd_config, add the configuration for the user group:

Match Group bastion-users
    AllowTcpForwarding yes
    X11Forwarding no
    PermitTunnel no
    GatewayPorts no

Real-world Operational Experience

After years of implementing this for large projects, here are a few tips for you:

Always have a backup plan: Set up an additional VPN channel. If the Bastion Host goes down, you still have a way to enter and rescue the system.
Log Rotation: Log files from the script command can take up gigabytes of space if users perform many tasks. Use logrotate to compress and delete old logs after 30 days.
Integrate 2FA: If possible, install Google Authenticator on the Bastion. This is a very strong security layer that helps you sleep better every night.

Summary

Setting up a Bastion Host is not difficult, but the effectiveness it brings is huge. It completely changes how you protect your infrastructure. Instead of struggling to patch vulnerabilities everywhere, you only need to focus on guarding a single point.

I hope these insights help make your systems more secure. If you encounter any difficulties during the configuration process, don’t hesitate to leave a comment, and I’ll get back to you right away!