Use or Space to navigate
Server+ Capstone · Week 2

Jump Box

A single hardened door into the network — and a foundation for everything that follows.
Presenter Hak Tang Course Server+ · Cybertex Lab Node team2 VM 100 / jumpbox

What is a jump box

A jump box is a small, intentionally boring server whose only job is to be the one place an administrator logs in from before reaching anything else.

What it does

  • Sits between the outside world and protected networks
  • Accepts SSH from approved sources only
  • Forwards admin sessions inward to LAN servers
  • Centralizes login auditing in one place

Why we build one

  • One host to harden, monitor, and patch carefully
  • Internal servers no longer need direct exposure
  • Every admin action passes a logged checkpoint
  • Compromise of a workstation does not equal LAN access

Where it sits in the topology

Internet │ ▼ ┌────────────────────────────────────────────────┐ │ Proxmox host — node team2 │ │ │ vmbr0 10.10.10.10/16 ← management LAN │ │ vmbr1 172.16.0.10/24 ← DMZ / Jump zone │ │ vmbr2 192.168.0.10/24 ← Private LAN │ │ │ └────────────────────────────────────────────────┘ │ ┌─────────┴─────────┐ ▼ ▼ vmbr1 (DMZ) vmbr2 (LAN) ┌──────────────┐ ┌──────────────┐ JUMP BOX │ Win Server │ 172.16.0.5 ──▶ │ Linux Srv │ └──────────────┘ └──────────────┘

The jump box lives in the DMZ. Internal servers on the LAN cannot be reached directly from outside — anyone administering them has to land on the jump box first.

VM specifications

Modest. A jump box does almost nothing — it should not need much.

FieldValue
VM ID / Name100 / jumpbox
Operating systemUbuntu Server 24.04 LTS
vCPU2 cores
Memory2 GB
Disk25 GB on local-lvm
Network deviceVirtIO on vmbr1 (ens18)
BIOS / MachineSeaBIOS / q35

Why minimal

A jump box is not a workhorse. Less RAM and fewer cores mean fewer services tempted to run on it. The smaller the surface, the easier the audit.

Network configuration

Set during the Ubuntu Server installer (Subiquity) — static IPv4 on the DMZ interface.

Method
Manual (static)
Subnet
172.16.0.0/24
Address
172.16.0.5/24
Gateway
172.16.0.10 — Proxmox host on vmbr1
Name servers
1.1.1.1, 8.8.8.8
Search domains
(none)

Why a static address

Firewall rules, SSH config, and any port forwarding all reference this address. DHCP would let it drift, breaking every rule that points at it. Static keeps the contract stable.

Install walkthrough

Ubuntu's Subiquity installer — eight screens, in order.

  1. Language — English
  2. Keyboard — English (US)
  3. Type of install — Ubuntu Server (full)
  4. Network — static IPv4 as shown on previous slide
  5. Proxy — leave blank
  6. Mirror — default archive
  7. Storage — entire disk, no LVM needed for this role
  8. Profile — non-root user, hostname jumpbox

User and SSH setup

Profile screen

  • Real name (cosmetic only)
  • Server name jumpbox
  • Username haktang — never root, admin, or ubuntu
  • Password 16+ characters, mixed types

SSH screen

  • Install OpenSSH server
  • Import SSH identity from GitHub
  • GitHub user: UbuntoGod
  • Public keys load automatically — password login can be disabled later

The hidden win here

Loading keys at install time means the box is reachable from the laptop the moment it boots, with no password ever traveling over the network. The hardening that comes next gets to start from a strong baseline.

Detach the install ISO and reboot

Before the VM reboots into the new install, the installer ISO has to be unmounted — otherwise the VM will keep booting back into the installer.

  1. Proxmox UI → select VM 100 (jumpbox)
  2. Open the Hardware tab
  3. Double-click the CD/DVD Drive row
  4. Set Storage to Do not use any media → OK
  5. Back in the VM console, choose Reboot Now

The VM will boot into Ubuntu and present a jumpbox login: prompt.

SSH hardening

The default Ubuntu SSH config is permissive. The jump box gets its own override file — additive, easy to audit, easy to roll back.

sudo nano /etc/ssh/sshd_config.d/hardening.conf

Port 2222
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers haktang
MaxAuthTries 3
MaxSessions 3
LoginGraceTime 20
ClientAliveInterval 300
ClientAliveCountMax 2

Apply with sudo systemctl reload ssh. Test from a second terminal before closing the first — if the new config is broken, you still have a way back in.

Host firewall — UFW

Inbound on the jump box is locked down to SSH only, and only from the networks an admin would legitimately come from.

# default posture
sudo ufw default deny incoming
sudo ufw default allow outgoing

# SSH from the management LAN and DMZ
sudo ufw allow from 10.10.10.0/24 to any port 2222 proto tcp
sudo ufw allow from 172.16.0.0/24 to any port 2222 proto tcp

# turn it on and check status
sudo ufw enable
sudo ufw status verbose

Why allow from networks, not just one IP

The administrator's laptop IP can change. Allowing the management subnet keeps things workable without weakening security meaningfully — the management subnet is already trusted.

Verification

Three checks before declaring it done.

1 · The VM has the right address

ip -4 addr show ens18
# expected: 172.16.0.5/24

2 · SSH is listening on the new port

sudo ss -tlnp | grep 2222
# expected: a sshd line on 0.0.0.0:2222

3 · A real SSH login works from the management network

ssh -p 2222 [email protected]
# expected: password-less key auth, drops into the prompt

What this enables next

The jump box is the foundation. With it in place, the rest of the lab can follow safely.

Now possible

  • Internal servers on vmbr2 can refuse all SSH that does not come from the jump box
  • A single set of admin keys controls access to every VM
  • Logs from one host show the full admin trail
  • Port forward from the host (DNAT) lets remote admins reach the jump box without exposing anything else

Common next steps

  • Install fail2ban on the jump box
  • Forward host port 2222 → jumpbox 2222 with iptables DNAT
  • Add reverse routes on internal VMs so they can reach the DMZ
  • Point internal VMs at the Windows Server VM for DNS

Takeaways

Smaller is safer
A jump box should do one thing. Less software, fewer ports, fewer ways to be wrong.
Static beats clever
Static IPs, fixed user names, and named ports make every other rule readable a year from now.
Test the new config from a second terminal
Always have a way back in before applying changes that affect SSH.
Defense in depth
UFW, SSH config, network segmentation, and Proxmox NAT all do part of the job. None is sufficient alone.
Document as you go
The next administrator is you in three months — leave a trail.
End of presentation

Questions

Topology, hardening choices, lab decisions — open floor.
Presenter Hak Tang Course Server+ · Cybertex Repo github.com/UbuntoGod
1 / 14