Bastion host

What a bastion host is and when you need one

A bastion host is one machine placed between the internet and the servers you want to protect. Instead of opening SSH on every database, application and worker node, you open it on the bastion only, and the internal machines accept SSH solely from the bastion's address. The NIST glossary defines the term as a special purpose computer designed and configured to withstand attacks, which is why the bastion should run as little software as possible.

The benefit is concentration. You harden, patch, monitor and log one entry point instead of many, and you can see who connected to which internal system. A bastion makes sense when you have several servers on a private network, a team of administrators, or a need to know who reached what. For a single VPS it is usually unnecessary: a well-configured SSH service with key-only login, covered in the SSH hardening guide, is the better use of your time.

Connecting through a bastion with ProxyJump

OpenSSH has built-in support. According to the ssh(1) manual, the -J option connects to the jump host first and then establishes TCP forwarding to the final destination from there. Several hops can be listed, separated by commas. It is a shortcut for the ProxyJump directive described in ssh_config(5).

A one-off connection looks like this:

ssh -J jump.example.com app.internal

For daily use, put the hops in ~/.ssh/config:

Host bastion
    HostName jump.example.com
    User ops

Host app
    HostName 10.0.0.12
    User deploy
    ProxyJump bastion

Now ssh app goes through the bastion, and other tools that read the same config, such as scp and sftp, follow the same route. The manual notes that options given on the command line apply to the destination, not to the jump hosts, so keep jump host settings in the config file.

Hardening the bastion

Treat the bastion as the most exposed machine you own. Start with key-based authentication only and add a second factor using the two-factor guide; AuthenticationMethods lets you require several methods. Install nothing except sshd and monitoring, allow inbound SSH only from known networks in the firewall, and set LogLevel VERBOSE instead of the default INFO, then ship the logs off the host (see the log analysis guide).

Do not enable agent forwarding to the bastion. The ssh manual warns that a user who can bypass file permissions on the remote host can use your forwarded agent to authenticate, and names a jump host as the safer alternative. Never store private keys on the bastion.

Note one exception to a typical hardening checklist: ProxyJump is TCP forwarding, so AllowTcpForwarding must stay enabled here. Limit it per key in authorized_keys, using options from sshd(8):

restrict,port-forwarding,permitopen="10.0.0.12:22" ssh-ed25519 AAAA...

Limits and alternatives

A bastion is not a cure-all. It is a single point of failure: if it is down, administrators lose access, so keep a provider console or a second path as a fallback. It is also a high-value target, because anyone who controls it sits on the path to your internal network. The sshd manual notes that disabling forwarding does not improve security unless users are also denied shell access, so give jump-only accounts no shell either.

Because the connection through a ProxyJump is a forwarded TCP stream, the bastion logs who connected to which destination, but not the commands typed inside the session. If you need command-level records, collect them on the target servers or use dedicated session-recording tooling.

The internal servers still need patching, least-privilege accounts and their own firewall rules. A VPN or your provider's private network is a common alternative when many services, not only SSH, must be reachable from a team. For one small server, skip the extra hop and harden direct access instead.

Related terms: SSH, Key-based authentication, Two-factor authentication, Firewall, authorized_keys, SSH agent forwarding.