Jump Gateway
A jump gateway is a single network server that forwards user traffic into private networks. Teams set it up by placing one hardened host between the public internet and internal servers. Most teams lock down the outer firewall and route all admin logins through this single box. Still, broad internal roles often let users run any command once they pass the outer door. How a native jump gateway works in practice In a standard setup, private servers sit inside a closed network subnet. These inte
SSH Bastion Hosts / Jump Servers + RDP Gateway: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A jump gateway is a single network server that forwards user traffic into private networks. Teams set it up by placing one hardened host between the public internet and internal servers. Most teams lock down the outer firewall and route all admin logins through this single box. Still, broad internal roles often let users run any command once they pass the outer door.
How a native jump gateway works in practice
In a standard setup, private servers sit inside a closed network subnet. These internal machines do not have public IP addresses. Instead, the team places one hardened Linux server on the network edge. Network rules allow incoming SSH traffic only to this single public host. Engineers first log in to the edge server using their personal SSH keys. From there, they open a second connection to reach the target database or app server. Modern SSH tools let users chain these two hops together in one step. The local client establishes an encrypted tunnel through the first server to the second server. System admins manage access by copying public keys onto the edge box and target machines. They also maintain local user accounts across the entire fleet of internal servers. When an engineer leaves the team, admins must remove their keys from every host.
What the network hop solves and what it misses
This traditional network pattern reduces the public attack surface of your private subnet. Attackers on the internet cannot scan or reach your internal databases directly. Security teams only need to watch and patch one public entry point. Firewalls block all unauthorized IP addresses before traffic ever reaches internal systems. Still, a network hop only checks who can enter the private subnet. Once the tunnel opens, the edge box cannot read the traffic inside it. If an engineer forwards a port to a database, the network host sees raw bytes. It does not know which SQL queries or shell commands the user runs. Also, teams often share one strong database role or root account on the target machine. That means any user who passes the outer check gets full write power inside. Admins cannot block a dangerous drop table statement or review individual queries in flight. Masking sensitive fields like emails, phone numbers, card numbers, or national IDs is also impossible at the network layer.
Managing keys and user roles across internal hosts
Relying on static SSH keys creates daily toil for platform teams. Every new server needs the right list of authorized public keys. When a contractor needs temporary access to fix a bug, someone must add their key manually. Often, nobody remembers to delete that key after the fix is done. Over time, internal hosts collect dozens of stale accounts with broad permissions. Using a central directory or host certificates reduces key sprawl across the fleet. Yet even with short-lived SSH certificates, the core problem remains the same. Host login checks only decide if a user can open a shell or port. They do not inspect database queries, limit shell commands, or rewrite sensitive data in results.
SSH Bastion Hosts / Jump Servers + RDP Gateway: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
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
What is the difference between port forwarding and agent forwarding?
Port forwarding routes network traffic from a local port to a remote server port. Agent forwarding lets a remote server use your local SSH keys to log in elsewhere. Security teams avoid agent forwarding because a compromised host can hijack the forwarded key socket.
Why is static key rotation hard on an entry server?
Static keys live in text files on the entry host and on every target machine. Rotating them requires updating files across many servers and asking every engineer to generate new keys. If one step fails, engineers get locked out during urgent outages.
Can a standard SSH hop filter database queries?
No, a standard SSH hop only forwards encrypted network packets between the client and target port. It does not parse database protocols or inspect the SQL statements running inside the tunnel. You need query-level controls to check statements or rewrite fields like card numbers in results.