Jump Station
A jump station is a hardened server that lets your team log in to private machines. You set it up by placing one host on a public subnet with strict firewall rules. Teams use this single entry point to keep database servers and app hosts off the public internet. Instead of opening ports on every machine, admins route all traffic through one audited box. Still, this setup often leads to shared keys and broad network permissions. Once a user lands on that first box, they often have full reach acr
SSH Bastion Hosts / Jump Servers: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A jump station is a hardened server that lets your team log in to private machines. You set it up by placing one host on a public subnet with strict firewall rules.
Teams use this single entry point to keep database servers and app hosts off the public internet. Instead of opening ports on every machine, admins route all traffic through one audited box. Still, this setup often leads to shared keys and broad network permissions. Once a user lands on that first box, they often have full reach across the private network.
How a jump station works in your network
To build a jump station, you first create a small virtual machine in a public network zone. You remove all extra tools, compilers, and storage mounts from this machine. Next, you set network rules so only known office IP addresses can reach the login port.
Your private servers sit in an isolated network zone with no public IP addresses. Their firewall rules only accept traffic coming from the internal address of the entry server. An engineer logs in to the entry host first, then opens a second session to the target box. Better yet, engineers use native forwarding so their local client routes traffic through the first host. This forwarding method keeps private keys off the middle server disk.
Managing keys and roles on the entry host
Running an entry server means you must track every user account and public key on that machine. When a new developer joins the team, an admin adds their public key to the host. When someone leaves, you must remove their key from the entry server and every private box.
Many teams sync these local accounts with a central directory or use certificate authorities. A certificate setup signs a user key for a short window, such as eight hours. This step stops old static keys from lingering on servers for months. You also need to patch the operating system on the entry box every week. Because this machine faces the internet, attackers will scan and probe it all day.
SSH Bastion Hosts / Jump Servers: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What the native setup solves and what it misses
A standard entry server shrinks your public attack surface down to a single hardened IP address. It gives network admins one place to put rate limits and IP allowlists. It also keeps your private databases and internal services hidden from public port scans.
Still, network routing only decides who can open a port between two machines. Once the tunnel is open, the entry host cannot see what happens inside the encrypted stream. It cannot tell if an engineer runs a safe read query or drops a production table. It also cannot rewrite sensitive fields like emails, phone numbers, or card numbers in query results. If a developer stores target database passwords on their laptop, the network jump does not protect those secrets. You get a clean network perimeter, but you still lack control over individual commands and queries.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Should we store private keys on the entry server?
No, you should never store private keys on the middle server. If an attacker compromises that host, they can steal every key stored on its disk. Always keep keys on the user workstation and forward the login request through the host.
How do we log activity on a standard entry host?
Standard network hosts only log when a connection starts, who logged in, and when it ends. Because traffic is encrypted end to end, the middle box only sees raw network packets. It cannot log specific database queries or shell commands run on the final target.
What happens if the entry server goes down?
If you run only one entry server and it fails, your team loses reach to all private hosts. Teams usually run two or more hosts across different zones behind a network load balancer. They also keep an emergency cloud console path open for break-glass recovery.