Relay Host Servers
You set up relay host servers by placing a single SSH node on your network edge. Engineers log in to this node first to reach private backend hosts. Most teams build this setup to keep internal databases and apps off the public web. Still, teams often give broad admin roles on the intermediate node to speed up daily work. When one engineer account is compromised, an attacker can reach every backend machine on the network. How relay host servers work in your network In a standard cloud network
SSH Bastion Hosts / Jump Servers: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up relay host servers by placing a single SSH node on your network edge. Engineers log in to this node first to reach private backend hosts. Most teams build this setup to keep internal databases and apps off the public web. Still, teams often give broad admin roles on the intermediate node to speed up daily work. When one engineer account is compromised, an attacker can reach every backend machine on the network.
How relay host servers work in your network
In a standard cloud network, private machines sit in isolated subnets with no public IP addresses. To reach them, admins place relay host servers in a public subnet with strict firewall rules. The firewall opens port twenty-two to known office IP addresses and blocks all other traffic.
An engineer starts a session from a laptop and forwards local keys through the middle node. The middle host checks the user key against a local list of allowed keys. Once the login succeeds, the user opens a second SSH tunnel to the final private machine.
Teams manage this flow by syncing SSH keys or linking a directory service to each host. System admins must update user lists on both the edge node and the backend fleet. If an employee leaves the team, admins must remove keys from every single server right away.
What native SSH routing solves and what it misses
Using a central entry host reduces your public attack surface right away. You no longer expose dozens of database ports or app servers to internet scanners. Admins have one network choke point to monitor for failed login attempts and brute force attacks.
Still, standard SSH routing only checks who can log in at the start of a connection. Once a session begins, the network rule cannot see or restrict what the user runs inside. An engineer with valid keys can run a drop table statement or read raw customer rows.
SSH Bastion Hosts / Jump Servers: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Also, sshd logs only show when a user opened a socket and which port they used. They do not record the actual SQL queries or shell commands sent through the encrypted tunnel. If someone copies a table full of phone numbers, your network logs only show byte counts. You also lack a way to require peer approval for a single risky command in flight. Native host routing forces an all-or-nothing choice between full shell access and no access at all.
Practical steps to tighten host permissions
First, turn off shell login on the middle host so users can only forward ports through it. Next, stop sharing root keys across the engineering team and assign unique Linux accounts per person. Map each user to a minimal Linux group that matches their daily job duties.
You should also replace static public keys with short-lived SSH certificates signed by a central authority. Certificates expire after a few hours, so stolen laptop files become useless by the next day. Still, host certificates only fix the login step and leave active sessions unchecked during runtime. To inspect live database queries and mask emails or card numbers, you need statement-level controls.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev sits inline in the wire protocol beside those services as an open-source proxy, a sidecar for your Postgres or API. On every query an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human review.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What is the difference between a relay host and a VPN?
A VPN puts a user laptop on the whole private network subnet. A relay host forwards specific protocol traffic like SSH to designated internal machines.
Should developers store private SSH keys on relay host servers?
No, you should never store private keys on intermediate machines. If an attacker reads that disk, they can impersonate every developer who stored a key there.
How do you audit commands run through an SSH tunnel?
Native SSH logs only show login times and network ports. To audit exact commands or database queries, you must inspect traffic at the protocol level.