Bastion Host: How to Centralize and Secure SSH Access to Your Servers

The invisible danger of exposing SSH directly to the cloud

Managing remote servers in the cloud requires secure connections, and the standard tool for this is the SSH protocol, short for Secure Shell, an encrypted channel that lets you control computers from afar via the command line. However, the most common mistake at the start of any project is opening the default port 22 directly to the public internet on every newly created virtual machine. In practice, this means any malicious bot scanning the global network will find your server within seconds and begin testing millions of credential and key combinations. Even with strictly key-based authentication, managing individual access across dozens or hundreds of scattered instances quickly becomes a catastrophic operational nightmare.

As a team grows, this problem multiplies exponentially. Developers join and leave, and each departure requires a manual sweep of dozens of servers to revoke that specific person's access, a process prone to severe human error. If a single peripheral server is compromised due to a vulnerability in outdated software, it becomes a beachhead for attackers to move laterally across the entire corporate infrastructure. To solve this security and governance dilemma, network engineering adopts the concept of a Bastion Host, a fortified server positioned strategically as the sole authorized entry point for an isolated private network.

What is a Bastion Host and how it works in practice

A Bastion Host, also known in technical slang as a jump box, functions exactly like the armored security gate of a high-end gated community. In network architecture, it is the only machine with a network interface connected directly to the public internet, while all other database instances and application servers reside in strictly private subnets, invisible to the outside world. When an engineer needs to perform maintenance on an internal server, they do not connect to it directly; instead, they establish a secure SSH connection to the Bastion Host and, from there, jump to the final destination within the isolated network.

In practice, this topology ensures that the defense perimeter is concentrated on a single point that can be monitored, hardened, and audited with maximum rigor. If the Bastion Host is properly configured, it becomes extremely difficult for an intruder to reach the internal servers, as they lack public IP addresses routable over the internet. This drastic separation of responsibilities transforms a chaotic scenario of dozens of open ports into a single, predictable, and highly restricted stream of encrypted network traffic.

Fundamental architectural decisions to harden your Bastion Host

Building a functional Bastion Host requires much more than simply spinning up a standard virtual machine in AWS or Google Cloud; it demands a rigorous hardening process. The first critical step is disabling absolutely any unnecessary service in the operating system, keeping only what is strictly essential for routing and controlling SSH connections. Direct root access via SSH must be disabled, forcing operators to log in with individual service accounts and elevate privileges through auditing tools like the sudo command, which logs every action taken in detail.

Another non-negotiable security pillar is the strict restriction of source IP addresses through security groups or edge firewalls. The Bastion Host should only accept connections from known corporate IP ranges or, preferably, through corporate virtual private networks (VPNs). Furthermore, password authentication must be permanently banned, exclusively allowing robust SSH keys combined with multi-factor authentication, ensuring that even if a private key is improperly copied, access still requires a dynamic second factor.

Implementing SSH tunneling and secure port forwarding

One of the greatest operational advantages of a Bastion Host is the ability to perform secure maintenance on databases and internal tools without exposing these applications to the public network. Instead of opening database ports to the internet, engineers use SSH port forwarding. In practice, the SSH command creates an encrypted channel that connects a local port on the developer's computer directly to the internal service through the jump box, simulating that the database is running locally on the operator's machine.

ssh -i ~/.ssh/id_rsa -L 5432:my-internal-db.local:5432 user@bastion-host-ip -N

This brilliant command establishes a tunnel where all traffic sent to the local port 5432 is encapsulated within the SSH session, passes through the Bastion Host invisibly to intermediaries, and is safely delivered to the internal database. To the database, it appears the request came from the Bastion Host itself on the local network, blocking any external direct access attempts. Thus, we eliminate the need for complex VPNs for one-off support tasks while maintaining end-to-end encryption and strict traceability.

Auditing, centralized logs, and the end of eternal static keys

A Bastion Host's security does not end at login; it critically depends on continuous observability of everything that happens during the session. Because all administrators are forced to pass through the jump box, the operating system can be configured to record all sessions into text files or binary logs using native auditing tools like script or terminal-based session recorders. In practice, this means that if a security incident occurs, the incident response team has an exact forensic record of every command typed by any user during remote access.

Beyond logs, managing static SSH keys—text files saved on developers' computers—remains a chronic security risk, as old keys from departed employees often linger in forgotten directories. The modern evolution of the Bastion Host solves this by integrating short-lived SSH certificate authorities, where keys automatically expire in a few hours. When an engineer wants to work, they authenticate with the company's identity provider and receive a temporary signed key, completely eliminating manual key file management and ensuring rigorous compliance with corporate auditing standards.

Final considerations on secure access centralization

Adopting a Bastion Host represents a profound mindset shift in infrastructure engineering, replacing the chaos of direct access with a centralized, auditable, and highly resilient model. Although it requires initial setup and maintenance effort, the gains in defense against automated intrusions and forensic traceability vastly outweigh the added complexity. As cloud environments continue to grow in scale and sophistication, protecting the front door is no longer a corporate luxury, but a basic technical survival requirement for any organization that takes data security seriously.