Bastion Server
Imagine your homelab has ten servers. Without a Bastion, your workstation can SSH directly to all ten. That means ten attack surfaces, ten sets of firewall rules to maintain, and ten places to harden. A Bastion is a single hardened server you put at the edge. Your workstation can only SSH to the Bastion. The ten internal servers only accept SSH from the Bastion. To reach any internal machine, you go through the Bastion first. One door, one lock, one audit trail. If something goes wrong, you have one place to look.
A Bastion server (also called a jump host or jump box) is a specially hardened server that provides controlled access to systems in a private network. It is the only server reachable from outside the network perimeter, and all internal hosts restrict SSH access to the Bastion’s IP only.
Network topology:
[Workstation] --SSH--> [Bastion :22 public] --SSH--> [Internal Servers]
|
[Firewall: only Bastion
can reach port 22
on internal hosts]SSH access methods:
ProxyJump (-J): Routes the TCP connection through the Bastion transparently.
ssh -J user@bastion user@internal-server
# Or in ~/.ssh/config:
# ProxyJump bastionThis creates a full TCP tunnel through the Bastion to the internal host. The Bastion sees the connection metadata but not the encrypted SSH payload.
Agent Forwarding (-A): Forwards the SSH authentication agent socket through the Bastion. When the internal server sends an auth challenge, it travels back through the tunnel to your local agent (and YubiKey). Used for hardware token authentication through hops.
Differences:
| Feature | ProxyJump | Agent Forwarding |
|---|---|---|
| Bastion sees auth? | No | Agent socket forwarded |
| Works with hardware tokens? | Yes (PKCS#11 direct) | Yes (agent-based) |
| Multi-hop? | Yes | Yes |
| Session recording | Not native | Can be added |
Hardening checklist:
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
X11Forwarding no
PermitTunnel no
AllowAgentForwarding yes
ClientAliveInterval 300
ClientAliveCountMax 2
MaxAuthTries 3
MaxSessions 2
LogLevel VERBOSEFirewall rules (iptables / nftables):
# Allow SSH to Bastion from anywhere
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# On internal hosts: allow SSH only from Bastion
iptables -A INPUT -p tcp --dport 22 -s BASTION_IP -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROPSession recording (optional but recommended):
Tools like tlog, asciinema, or teleport can record every command run in Bastion sessions for audit and incident response.
Bastion servers are standard in cloud infrastructure. AWS, GCP, and Azure all offer managed Bastion services, and every cloud architecture guide recommends them for private subnet access. In a homelab running Proxmox or similar, the Bastion is often a lightweight LXC container or minimal VM - it does not need resources, just a hardened SSH config and a static IP. The pattern becomes especially powerful when combined with hardware token authentication: the Bastion eliminates the need to expose every server, and the YubiKey eliminates passwords. Together, the only way into your homelab is: physical possession of a hardware token, knowledge of its PIN, and access to the one IP where the Bastion listens. Every access attempt is logged in one place. For incident response, that single audit trail is invaluable.