Jumping Server
A jumping server is a single hardened host that routes traffic to private machines. You log in to this public host first, and then reach internal systems. Most teams set up this host in a public subnet with strict firewall rules. When roles on that host are too broad, anyone inside can reach every private box. One stolen key gives an attacker a clear path across your whole internal network. How a jumping server works in your network Your private databases and app hosts sit inside a locked net
Kubernetes API Server Access: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A jumping server is a single hardened host that routes traffic to private machines. You log in to this public host first, and then reach internal systems. Most teams set up this host in a public subnet with strict firewall rules. When roles on that host are too broad, anyone inside can reach every private box. One stolen key gives an attacker a clear path across your whole internal network.
How a jumping server works in your network
Your private databases and app hosts sit inside a locked network subnet. Those private machines do not have public IP addresses at all. No one on the open internet can send traffic straight to them. Instead, the team places one hardened Linux machine at the network edge. That single machine serves as your jumping server for all remote work.
Engineers start an SSH session from their laptops to that public machine. Network firewalls block all outside ports except the single SSH port on that host. Once the host checks the user key, the user lands on the edge box. From there, the user opens a second session to a private host inside. Good setups forward the local SSH agent so private keys never sit on the disk.
Admins also lock down the edge host by removing extra tools and compilers. They map each person to a local Linux role with specific group rules. System logs record which user key opened a session and when it closed. Teams must update those local user lists every time an engineer joins or leaves.
What the native setup solves and what it misses
This edge host design shrinks your public attack surface right away. You do not need to expose dozens of SSH ports to the internet. You only patch, watch, and guard one public entry point for the team. Network rules become much simpler because internal hosts only trust traffic from that one IP.
Yet this network layout only decides who can open a door into the subnet. Once a session connects to an internal machine, the edge host goes blind. It does not inspect individual shell commands or database queries in flight. A user with a valid key can run a bad delete command by mistake.
They can also read raw production tables that hold emails, phone numbers, or card numbers. Standard network logs only show that a TCP stream happened between two IP addresses. They do not show what commands ran or what data came back. Static SSH keys also linger on laptops long after a task ends. If an engineer loses a laptop, admins must rotate keys across many hosts by hand.
Kubernetes API Server Access: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
How to harden your jumping server setup
Start by turning off password logins on the edge host right away. Force every user to log in with a strong SSH key pair instead. Better yet, use a central certificate tool to sign user keys for short periods. That way, you do not have to copy static key files to every server.
Next, block users from opening an interactive shell on the edge machine itself. Configure the SSH daemon so it only allows TCP port forwarding to internal hosts. That stops engineers from leaving local files, scripts, or keys behind on the shared box. Keep the host operating system minimal and set up automatic security updates every day.
Finally, ship all login logs from the edge host to a remote log store. If an attacker breaks into the box, they cannot wipe remote records of their entry. Pair those login events with strict host firewall rules on every internal machine. Even inside the private network, each app host should only accept traffic from needed roles.
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 jumping server and a VPN?
A VPN links a user laptop straight into the private network for all traffic. A jumping server only forwards specific admin sessions like SSH from a single guarded host.
Should you store private SSH keys on the edge host?
Never store private keys on the shared edge machine because root users can read them. Keep private keys on the user laptop and forward the login request through the session.
Why do network logs fail most security audits?
Network logs only record IP addresses, port numbers, and timestamps for each session. Auditors need to see the exact shell commands and database queries that each person ran.