Back to tutorials
Tutorial

SSH Jump Host Setup Guide Tutorial (2026): Secure Admin Access to VPS and Dedicated Servers Without Exposing Panels

SSH jump host setup guide tutorial for safer VPS admin: keys, MFA, firewall rules, and private access to panels and services.

By Anurag Singh
Updated on Jul 04, 2026
Category: Tutorial
Share article
SSH Jump Host Setup Guide Tutorial (2026): Secure Admin Access to VPS and Dedicated Servers Without Exposing Panels

You don’t need WHM, phpMyAdmin, Redis, or even SSH exposed to the whole internet to run a hosting stack. In 2026, the clean pattern for small teams and resellers is a hardened jump host (bastion). It’s the only box with public SSH.

This SSH jump host setup guide tutorial is a practical, copy‑paste setup. You’ll run it on a small VPS. Then you’ll use it to reach private admin ports on other VPS or dedicated servers.

This guide targets real hosting operations: a cPanel server, a WordPress VPS, plus a mail relay or monitoring node.

You’ll end up with one tightly controlled entry point. It enforces key-based SSH, optional 2FA, and clear rules for who can reach what.

SSH jump host setup guide tutorial: What you’re building (and why it beats “open port 22 everywhere”)

Here’s the target layout:

  • Jump host (public): one small VPS with a public IP and port 22 open (or a custom port if you prefer). This is the only server exposed for SSH.
  • Target servers (private): your hosting VPS/dedicated servers where SSH and admin ports bind to private IPs, or are firewalled to only accept from the jump host.
  • Your laptop (client): you connect to the jump host, then hop to targets using OpenSSH ProxyJump.

The wins show up quickly:

  • Less public surface area. You harden and monitor one SSH endpoint.
  • Simpler firewall policy. Targets can drop inbound SSH from the internet entirely.
  • Safer admin access. You can reach private ports (WHM 2087, Plesk 8443, DirectAdmin 2222, SMTP admin endpoints, etc.) without publishing them.

If you want a stable, low-latency jump host near your other servers, start with a HostMyCode VPS and keep it small.

For most teams, 1 vCPU and 1–2 GB RAM is plenty.

Prerequisites and assumptions

  • Jump host: Ubuntu Server 24.04 LTS (or Debian 12). Commands below use Ubuntu paths and systemd.
  • Targets: any Linux (Ubuntu/Debian/AlmaLinux/Rocky) with OpenSSH server installed.
  • You have sudo on all servers.
  • You can set firewall rules (UFW, nftables, firewalld, or provider security groups).

Throughout the tutorial, replace these placeholders:

  • JUMP_PUBLIC_IP (public IP of jump host)
  • JUMP_PRIVATE_IP (private IP of jump host if you use private networking)
  • TARGET_PRIVATE_IP (private IP of a target server)
  • admin (your admin username; avoid root)

Step 1 — Provision the jump host and create an admin user

Log in to the jump host using your provider’s initial access method (temporary password, console, or preloaded key).

Then create a dedicated admin user:

sudo adduser admin
sudo usermod -aG sudo admin

On Ubuntu, patch first. Then reboot once:

sudo apt update
sudo apt -y full-upgrade
sudo reboot

If this jump host supports production hosting work, managed VPS hosting can be a sane choice.

It keeps patching, baseline hardening, and monitoring from becoming “whoever remembers this week.”

Step 2 — Generate SSH keys (and stop using passwords)

On your laptop (macOS/Linux):

ssh-keygen -t ed25519 -a 64 -f ~/.ssh/hmc-jump-admin

Copy the public key to the jump host:

ssh-copy-id -i ~/.ssh/hmc-jump-admin.pub admin@JUMP_PUBLIC_IP

Now lock down SSH on the jump host. Edit /etc/ssh/sshd_config:

sudo nano /etc/ssh/sshd_config

Set (or confirm) these values:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
X11Forwarding no
AllowUsers admin

Validate the config and reload SSH:

sudo sshd -t
sudo systemctl reload ssh

If you ever lock yourself out while changing SSH settings, keep a recovery runbook nearby: Firewall troubleshooting tutorial for locked-out SSH.

Step 3 — Add basic firewall rules on the jump host (UFW)

For a dedicated jump host on Ubuntu, UFW is enough.

Use default-deny inbound, allow outbound, then open SSH:

sudo apt -y install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

If you can restrict SSH to your office IP ranges, do it here:

sudo ufw delete allow 22/tcp
sudo ufw allow from YOUR_OFFICE_PUBLIC_IP to any port 22 proto tcp

If your team doesn’t have stable IPs, a VPN is usually the cleanest answer.

If that’s not realistic, keep SSH public and add 2FA in the next step.

Step 4 — Optional: add SSH 2FA on the jump host (practical, not fragile)

SSH keys are the baseline. 2FA helps if a key leaks or gets copied somewhere it shouldn’t.

On Ubuntu 24.04, a straightforward option is PAM-based TOTP using libpam-google-authenticator.

sudo apt -y install libpam-google-authenticator

Switch to your admin user and enroll:

su - admin
google-authenticator

Answer the prompts conservatively (time-based tokens, disallow reuse, rate limit).

Enable it in PAM:

sudo nano /etc/pam.d/sshd

Add this line near the top:

auth required pam_google_authenticator.so nullok

Now allow the challenge step without turning passwords back on. Edit /etc/ssh/sshd_config:

KbdInteractiveAuthentication yes
AuthenticationMethods publickey,keyboard-interactive

Reload:

sudo sshd -t
sudo systemctl reload ssh

Pitfall: document your break-glass path before enforcing 2FA (provider console / IPMI / rescue).

If TOTP fails (clock drift, lost device), you’ll need a way back in.

Step 5 — Set up target servers to accept SSH only from the jump host

You have two common options.

Pick one approach, then use it consistently across your fleet.

Option A: Targets have private networking (best)

Put SSH on a private interface. Then don’t accept public SSH at all.

On the target server, confirm the private IP:

ip a

Configure SSH to listen on the private IP only. Edit /etc/ssh/sshd_config:

ListenAddress TARGET_PRIVATE_IP

Reload:

sudo sshd -t
sudo systemctl reload ssh

This is the cleanest model. It depends on private routing between the jump host and targets.

Option B: Targets keep public networking, but firewall SSH to the jump host

On the target server (Ubuntu + UFW example):

sudo apt -y install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow from JUMP_PUBLIC_IP to any port 22 proto tcp
sudo ufw enable
sudo ufw status

On AlmaLinux/Rocky with firewalld, the policy is the same.

Allow port 22 only from the jump host IP.

Checklist: before you flip a web server to strict inbound rules, confirm what’s actually listening.

Make sure you’ve allowed 80/443 and any mail ports you host (25/465/587/993/995). Don’t rely on guesses.

Step 6 — Configure ProxyJump on your laptop (clean SSH config)

Edit ~/.ssh/config on your laptop:

Host hmc-jump
  HostName JUMP_PUBLIC_IP
  User admin
  IdentityFile ~/.ssh/hmc-jump-admin
  IdentitiesOnly yes
  ServerAliveInterval 30
  ServerAliveCountMax 3

Host web-01
  HostName TARGET_PRIVATE_IP
  User admin
  ProxyJump hmc-jump
  IdentityFile ~/.ssh/hmc-jump-admin
  IdentitiesOnly yes

Now connect to the target. SSH will hop through the jump host automatically:

ssh web-01

If you manage multiple machines, add more Host blocks.

The file stays readable as you add customers and nodes.

Step 7 — Reach private admin panels without making them public (port forwarding examples)

This is the payoff. You keep sensitive ports closed to the internet. You still access them comfortably from your laptop.

Example: Access WHM (2087) on a private cPanel server

From your laptop:

ssh -J hmc-jump -L 2087:127.0.0.1:2087 admin@TARGET_PRIVATE_IP

Then open:

https://localhost:2087

If WHM isn’t bound to localhost, forward to the server’s internal address instead.

Keep the destination as narrow as you can.

Example: Reach a private Grafana or Netdata port for troubleshooting

ssh -J hmc-jump -L 19999:127.0.0.1:19999 admin@TARGET_PRIVATE_IP

If you want the broader pattern (and the common gotchas), see: SSH port forwarding tutorial for hosting admin ports.

It covers safe binds, typical mistakes, and troubleshooting.

Step 8 — Lock down SSH agent forwarding (and know when not to use it)

Agent forwarding (-A) feels convenient until it isn’t.

If the jump host is compromised, a forwarded agent can become a pivot point.

For hosting operations, the usual rule set is simple:

  • Prefer ProxyJump with local keys over agent forwarding.
  • If you must use agent forwarding, enable it only for specific hosts and only for short-lived work.

You can explicitly disable agent forwarding in your jump host entry:

Host hmc-jump
  ForwardAgent no

Step 9 — Add auditability: logging and simple alerting for jump-host SSH

Once admin access funnels through one machine, logs stop being a scavenger hunt.

You get one place to review auth events and failures.

On Ubuntu, SSH auth events are in /var/log/auth.log. Quick checks:

sudo grep "sshd" /var/log/auth.log | tail -n 50
sudo grep "Failed password" /var/log/auth.log | tail -n 20
sudo last -a | head

If you want centralized logs (handy once you manage several nodes), follow: log shipping with rsyslog + TLS.

Ship jump-host SSH logs and target logs to one place.

Step 10 — Common failure modes (and how to diagnose quickly)

  • “Permission denied (publickey)” on the jump host: confirm the correct key is used (ssh -v hmc-jump) and ~/.ssh/authorized_keys permissions are correct (700 ~/.ssh, 600 authorized_keys).
  • Jump works, but target hop times out: the target firewall probably doesn’t allow SSH from the jump IP, or private routing is missing.
  • Port forward connects but browser shows TLS errors: this is common when the panel uses a hostname-based certificate. Use the correct URL/host header when possible, or accept the private/admin cert for internal access.
  • You cut off your own SSH during firewall changes: use your provider console, then validate rules. This guide helps: diagnose blocked ports and SSH lockouts.

Step 11 — A practical hardening checklist for hosting teams

  • Jump host: keys only, root login disabled, admin user only, optional TOTP 2FA.
  • Jump host firewall: allow SSH only from office/VPN if possible.
  • Targets: accept SSH only from jump host IP (or listen on private interface only).
  • Admin panels: do not expose to the internet. Use SSH local forwards for WHM/Plesk/DirectAdmin.
  • Document break-glass access: provider console steps, who can use it, and when.
  • Log review: weekly scan of jump-host auth logs; alert on repeated failures.

If you also need secure file transfers for clients or developers, don’t turn your jump host into an FTP server.

Set up SFTP properly per user and restrict paths. This guide is solid: SFTP setup guide for locked-down transfers.

If you want a jump host that stays predictable under constant scanning and login noise, start with a small HostMyCode VPS and keep it dedicated to access control. If you’d rather not own the patch-and-harden routine, managed VPS hosting can handle baseline hardening and ongoing updates while you focus on sites and customers.

FAQ

Do I still need a firewall on the targets if I use a jump host?

Yes. The jump host reduces exposure, but the target firewall enforces it.

Restrict SSH to the jump host IP and only open service ports you actually provide (80/443, mail ports if applicable).

Should the jump host run anything besides SSH?

Keep it boring. SSH, firewall, and logging are enough.

Don’t host websites, databases, or mail on the jump host unless you have a very specific reason.

Can I manage cPanel/WHM safely through a jump host?

Yes. Keep WHM closed publicly and use SSH local port forwarding to localhost:2087 or the server’s private interface.

It’s a simple way to avoid exposing admin panels.

What’s the safest way to handle multiple admins?

Create a separate Linux user per admin on the jump host, each with their own SSH key (and optionally 2FA).

Avoid sharing keys. Disable accounts immediately when access changes.

Is a jump host worth it for one VPS?

If you’re the only admin and you already restrict SSH by IP, maybe not.

If you’re running client hosting, reseller operations, or multiple servers, it pays for itself quickly in reduced risk and simpler access control.

Summary: your new default admin entry point

A jump host is a rare change that tightens security and makes daily admin work easier.

You expose one SSH endpoint and harden it properly. You also stop publishing admin panels to the internet.

Targets stay quieter, firewall rules get simpler, and incident response speeds up because the access trail is centralized.

If you’re setting this up alongside production sites, run the jump host on a dedicated instance from HostMyCode VPS so it doesn’t compete with web workloads.

Scale up to dedicated servers when your hosting fleet grows and you need predictable performance.