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.
| Field | Value |
| VM ID / Name | 100 / jumpbox |
| Operating system | Ubuntu Server 24.04 LTS |
| vCPU | 2 cores |
| Memory | 2 GB |
| Disk | 25 GB on local-lvm |
| Network device | VirtIO on vmbr1 (ens18) |
| BIOS / Machine | SeaBIOS / 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.
- Language — English
- Keyboard — English (US)
- Type of install — Ubuntu Server (full)
- Network — static IPv4 as shown on previous slide
- Proxy — leave blank
- Mirror — default archive
- Storage — entire disk, no LVM needed for this role
- 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.
- Proxmox UI → select VM 100 (jumpbox)
- Open the Hardware tab
- Double-click the CD/DVD Drive row
- Set Storage to
Do not use any media → OK
- 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.
sudo ufw default deny incoming
sudo ufw default allow outgoing
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
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
2 · SSH is listening on the new port
sudo ss -tlnp | grep 2222
3 · A real SSH login works from the management network
ssh -p 2222 [email protected]
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