Bastion Host: How to Build a Secure Server Access Point

The Critical Problem of Direct Server Exposure in the Cloud

When we deploy a server on the cloud or a physical data center, we open doors for computers worldwide to communicate with it. If we leave the standard remote administration port, such as port 22 for secure terminal access via SSH, directly exposed to the public internet, we immediately start receiving thousands of automated intrusion attempts daily. Malicious bots scan the network looking for weak passwords or unpatched vulnerabilities. In everyday terms, this is like leaving the front door of a commercial store completely unlocked on a busy street, trusting that nobody will try the handle.

To solve this dilemma without hindering engineers, network engineering adopts a fundamental concept known as a bastion host or jump server. In practice, this is an isolated, heavily fortified computer placed at the forefront of the network. It acts as the single authorized gateway of a gated community. No one can talk directly to the internal servers holding databases or core applications; all connections must pass strictly through this rigorous checkpoint, validating the visitor's identity before permitting any further step.

Network Architecture and Private Instance Isolation

Building a secure architecture requires a clear separation between public and private networks. In modern cloud environments, this is achieved using isolated virtual networks, known as VPCs, dividing the terrain into public zones that accept internet traffic and private zones housing application and data servers that should never face the public internet directly. The bastion host is the sole machine residing in the public zone with outward-facing ports, while other instances hide in isolated subnets, communicating only with each other and the bastion itself.

This topology eliminates the risk of unrestricted lateral movement. If a database server were on the internet and compromised, the attacker would gain full control of the machine. With the bastion host acting as an intermediary, even if an intruder breaches the internal network, they encounter rigorous internal firewall barriers and restricted traffic rules. In practice, this means layered topology turns a potential widespread disaster into a contained incident, because communication ports between internal servers are closed to any traffic not originating from the bastion's authorized IP address.

Practical Implementation and Hardening Configuration

Creating a functional bastion host requires a rigorous system hardening process. This involves stripping away unnecessary software, disabling risky services, and configuring the operating system to accept only the bare minimum. The first step is changing the default SSH port to a non-standard port, reducing the noise from automated vulnerability scans. Next, we completely disable password authentication, permitting access exclusively through highly secure asymmetric cryptographic key pairs.

In the SSH server configuration file, typically located at /etc/ssh/sshd_config, we apply strict directives to block direct root logins and limit user connections. Below is an example of essential security directives:

Port 22222
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers [email protected]
X11Forwarding no
AllowTcpForwarding yes

In practice, this configuration snippet ensures that only a specific user coming from a trusted corporate IP address can establish an initial connection, keeping the encrypted tunnel closed to any other origin.

SSH Tunneling and Port Forwarding to Internal Servers

Once an engineer successfully authenticates with the bastion host, the need arises to reach servers residing on the private network without public IPs. Instead of punching new holes in internal firewalls, we use the SSH protocol itself to build a secure encrypted tunnel. This mechanism redirects a local port from the developer's machine through the bastion directly to the service port of the hidden internal server, keeping all communication shielded against network eavesdropping.

To perform this connection in practice, we use dynamic tunneling or local port forwarding commands. For example, to access a PostgreSQL database running on a private internal instance via the bastion, we execute a command similar to this in our local terminal:

ssh -i ~/.ssh/id_rsa -p 22222 -L 5432:db-interno.local:5432 [email protected] -N

By running this command, the developer can point their local database client to localhost:5432, and all traffic is transparently encapsulated by the bastion host until it reaches the target server in the private zone, without exposing the database to the rest of the network.

Auditing, Monitoring, and Access Log Management

A bastion host serves not only to block unwanted access but also to rigorously log everything happening at the infrastructure's front door. Since all administrative traffic flows through it, the jump server becomes the perfect central point for security auditing. We must configure the operating system's event logging facility to ship copies of all authentication logs and access attempts to a centralized log server or real-time security analytics tool.

Beyond traditional connection logs, modern bastion tools allow terminal session recording, capturing every command typed by engineers in text or lightweight video formats. This ensures compliance with stringent regulatory standards and provides immediate forensic visibility if anomalous behavior occurs. In practice, knowing precisely who accessed the environment, from which IP, and at what time eliminates operational grey areas and clearly holds each operator accountable for system maintenance.

Final Thoughts on Access Governance

Adopting a bastion host represents a turning point in the operational maturity of any software engineering or infrastructure team. By centralizing the entry point into a single fortified checkpoint, we drastically reduce the attack surface, remove the need to expose private instances directly to the internet, and guarantee full traceability over performed operations. While it demands discipline in initial setup and ongoing key management, the payoff in peace of mind and security far outweighs the architectural effort.

Ultimately, information security does not rely on a single magic tool, but on the intelligent combination of network isolation, robust encryption, and constant auditing. The bastion host is the core piece that materializes this philosophy, enabling teams to operate their systems with agility without sacrificing the rigorous control indispensable to modern production environments.