Jump Server (Bastion Host): Definition, How It Works, and Where You’ll See It
A jump server is an intermediary system used to access servers and devices that are not directly reachable from a user’s network. It centralizes and controls privileged access, usually by allowing inbound admin connections to the jump server and only allowing onward connections from it to internal targets.
A jump server (also called a bastion host) is a hardened gateway that brokers privileged access to systems on private or segmented networks. In practice, it’s the controlled “stepping stone” admins use to reach internal targets over SSH/RDP while keeping exposure, authentication, and logging centralized.
How a jump server works
At a high level, a jump server creates a controlled “stepping stone” for administrative sessions—reducing the number of systems exposed to user networks or the internet and improving visibility over privileged activity.
Typical access flow
-
Admin connects to the jump server
The administrator establishes an SSH or RDP session to the jump server from a trusted network (corporate LAN, VPN, or another controlled segment). -
Authentication and policy checks happen at the jump point
Common controls include: - MFA (preferably phishing-resistant) - SSO/IdP integration - IP allowlists / conditional access policies - Device posture checks (managed endpoint, EDR present) -
Admin “jumps” from the jump server to internal targets
From the jump server, the admin initiates a second connection to the internal server or device (e.g., SSH to a Linux server, RDP to a Windows server, SQL admin tool to a database management host). -
Logging and monitoring capture activity
Because privileged access funnels through one choke point, defenders can record: - Successful/failed logons - Session start/stop - Commands typed (if session recording is implemented) - File transfers (SCP/SFTP, clipboard, drive mapping)
Network placement and trust boundaries
A jump server is usually placed in a network zone that can be reached by admins but has tightly controlled pathways into deeper segments:
- On-prem: commonly in a DMZ-like admin zone or dedicated management VLAN.
- Cloud: commonly in a public subnet with a restricted security group (or in a private subnet accessed via VPN/Direct Connect/peering, depending on design).
The most important design principle: Only the jump server is reachable from the admin entry network, and only required management ports are allowed from the jump server to the internal network.
Hardening expectations (jump server vs. “just another server”)
A real jump server is intentionally hardened because it becomes a high-value target:
- Minimal software installed (reduce attack surface)
- No email/web browsing; ideally no general internet access
- Strong authentication (MFA, short session lifetimes)
- Tight egress rules (only to management ports/destinations)
- Centralized logs and alerting (SIEM integration)
- Frequent patching and vulnerability scanning (tie this to your broader program—see patch management best practices a practitioners guide)
- Separate administrative identities (no day-to-day accounts)
Common connection patterns (SSH and RDP)
SSH “jump host” usage (client-side)
Many teams use SSH’s built-in proxying so admins don’t have to maintain long-lived shells on the jump server.
# One-off: reach a private host via jump server
ssh -J admin@jump.example.com admin@10.10.20.15
# Equivalent using ProxyJump in SSH config
cat <<'EOF' >> ~/.ssh/config
Host private-*
User admin
ProxyJump admin@jump.example.com
Host private-db
HostName 10.10.20.15
EOF
ssh private-db
Operational tip: enforce key-based auth and restrict which keys/users can access which internal hosts using AllowUsers, Match, and forced commands where appropriate.
RDP via jump server (two-step)
A common pattern is:
1) RDP to jump server
2) From jump server, RDP to internal Windows server
If you must allow RDP, reduce risk by disabling clipboard/drive redirection and enabling NLA, MFA, and session timeouts.
Example firewall intent (conceptual)
- Inbound to jump server: allow SSH (22) and/or RDP (3389) only from VPN ranges or admin workstations.
- Outbound from jump server: allow SSH/RDP/WinRM only to specific internal subnets; deny all else.
Logging and monitoring: what to capture
Linux jump server (SSH) log patterns
On many distros, SSH authentication events show up in:
/var/log/auth.log(Debian/Ubuntu)/var/log/secure(RHEL/CentOS/Rocky/Alma)
Useful quick checks:
# Recent successful SSH logins
grep -E "sshd\[[0-9]+\]: Accepted" /var/log/auth.log | tail -n 50
# Failed login attempts
grep -E "sshd\[[0-9]+\]: Failed|Invalid user" /var/log/auth.log | tail -n 50
Look for: - Logins at unusual hours - New source IPs - Repeated failures followed by a success - Use of unexpected accounts
Windows jump server (RDP) event IDs to monitor
Common Windows logs for RDP and logons: - 4624 (successful logon) with Logon Type 10 (RemoteInteractive) - 4625 (failed logon) - 4776 (credential validation, often seen with NTLM)
PowerShell query example:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} |
Where-Object { $_.Message -match "Logon Type:\s+10" } |
Select-Object -First 20 TimeCreated, Id, Message
Where you’ll encounter a jump server
Jump servers show up wherever direct administrative access would be too risky, too noisy, or simply not possible due to segmentation.
1) Private subnets and segmented networks
In mature environments, production servers are not reachable from user networks. Instead, admins enter through a management choke point (the jump server) to reach:
- Linux/Windows servers
- Hypervisors
- Network devices (routers, switches, firewalls)
- Management planes for storage and backup systems
2) Cloud environments (especially “no public IP” designs)
In cloud architectures, workloads often sit in private address space without public exposure. A jump server (or jump service) becomes a practical way to access:
- Instances with no public IP
- Private databases via management hosts
- Kubernetes worker node SSH (where allowed)
- Internal web admin panels only accessible from private networks
Even when a VPN exists, teams still use jump servers to reduce the blast radius and keep privileged access observable. If you’re evaluating consumer-style VPN tools for small admin teams (not as a replacement for enterprise remote access controls), options like NordVPN (Check NordVPN pricing →) or Surfshark (Try Proton VPN →) can be a pragmatic stopgap for encrypting traffic on untrusted networks—but still keep administrative pathways constrained through the jump server.
3) Incident response and containment
During an incident, organizations sometimes force all admin access through a jump server to:
- Limit lateral movement from compromised endpoints
- Centralize audit logs for privileged actions
- Apply temporary controls (IP restrictions, time-based access)
This is particularly common if there is suspicion that end-user devices or credentials are compromised. For threat-modeling the “how did they move?” storyline, mapping jump server misuse to attacker stages can help—see what is the cyber kill chain.
4) OT/ICS and high-sensitivity networks
Operational Technology networks (manufacturing, utilities) often require strong separation from IT networks. A jump server provides controlled access for:
- Vendors performing maintenance
- Engineers accessing HMIs and controllers indirectly
- Time-limited, monitored support sessions
In these environments, jump servers may be paired with strict allowlists, session recording, and removable-media restrictions.
5) Compliance-driven access control
Regulated environments use jump servers to satisfy requirements around: - Segregation of duties - Auditability of privileged access - Controlled administrative pathways
Even if not explicitly mandated, auditors often expect a story for how privileged access is constrained and logged.
Quick sanity checklist (operator-focused)
Jump server minimum checklist:
- MFA enforced for interactive access
- Admins use separate privileged accounts
- Inbound access restricted (VPN/admin IPs only)
- Outbound restricted to required management ports/targets
- Central logging enabled (auth + session telemetry)
- No direct internet browsing; minimal packages installed
- Regular patching + vulnerability scanning
- Alerting on new source IPs, brute force, and off-hours logons
If your jump server is broadly reachable, unmonitored, or allowed to connect anywhere internally, it’s not a safety control—it’s a single point of compromise.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.
Related terms
Often synonymous with jump server; typically emphasizes an internet-facing hardened entry point into a private network.
A broader set of controls (vaulting, just-in-time access, approvals, session recording). A jump server can be part of a PAM architecture or replaced by PAM brokers.
A dedicated, hardened admin endpoint. PAWs reduce endpoint risk; jump servers reduce network exposure. Many mature shops use both.
Provides network reachability into private subnets. A jump server provides controlled administrative access and a logging choke point; they’re complementary, not identical.
A Microsoft role that brokers RDP over HTTPS; similar goal (controlled access) but implemented as a gateway service rather than a general-purpose server.
The SSH-specific implementation/pattern for jumping to private hosts using ProxyJump or ProxyCommand.
A perimeter network segment. Jump servers are often placed in a DMZ-like admin zone, but a DMZ is a network design concept, not an access method.
Security models that limit east-west movement. Jump servers are a practical tool to enforce segmentation for administrative paths.
Capturing administrator sessions (keystrokes, screen video, command logs). Often used on jump servers to improve accountability and forensic readiness.