SSH Port Forwarding Tutorial (2026): Securely Reach cPanel, Webmail, and Admin Dashboards Without Opening New Ports

You can shrink your attack surface without changing your application stack. Stop exposing “just one more admin port.” Reach those interfaces through SSH instead. This SSH port forwarding tutorial shows how to access cPanel/WHM, webmail, phpMyAdmin, and private app dashboards from your laptop through one hardened SSH entry point.

This approach fits day-to-day hosting work. You keep public ports limited (usually 80/443 plus SSH). You still get dependable access during migrations, incident response, and routine admin tasks.

What you’ll build (and why hosting admins use it)

By the end, you’ll have a repeatable setup to:

Reach internal-only services (cPanel on 2083, WHM on 2087, webmail on 2096, custom admin panels) without exposing them to the internet.
Use localhost URLs in your browser that map to your server’s private ports.
Optionally create a safer “jump” path for servers where SSH shouldn’t be directly reachable from everywhere.

If you’re setting up a new server, harden SSH first. Use keys, MFA, and sensible access control.

HostMyCode’s managed VPS hosting works well if you want help locking down access while you focus on sites and clients.

Prerequisites and a quick safety checklist

You’ll need:

A VPS or dedicated server with SSH access (Ubuntu 22.04/24.04, Debian 12, AlmaLinux 9/10, Rocky 9 all work).
An SSH key on your workstation (recommended) and a user that can log in via SSH.
Basic comfort with a terminal on macOS/Linux, or PowerShell/Windows Terminal on Windows.

Before you start tunneling, confirm your SSH baseline:

Keys enabled; password login disabled (or at least restricted).
Root login disabled.
Fail2Ban or equivalent login throttling, and logs monitored.

Need a hardening reference? Follow this SSH hardening tutorial first, then come back.

Step 1: Identify what you want to tunnel (cPanel, webmail, admin panels)

Start by listing the service you need and the port it listens on. Common hosting examples:

WHM (SSL): 2087
cPanel (SSL): 2083
Webmail (SSL): 2096
phpMyAdmin (often behind a URL path on 443, but sometimes a private port): e.g. 127.0.0.1:8080
DirectAdmin: 2222
Plesk: 8443

Best practice for 2026: bind admin tools to 127.0.0.1 or a private interface on the server. Then tunnel in over SSH.

This adds a second layer of protection if a firewall rule changes later.

Step 2: Create a local port forward (single service)

A local forward maps a port on your laptop to a host:port reachable from the SSH server.

Here’s the basic pattern:

ssh -L LOCAL_PORT:DEST_HOST:DEST_PORT user@SERVER_IP

Example: access WHM (2087) safely

ssh -L 12087:127.0.0.1:2087 admin@203.0.113.10

Keep that SSH session running. Then open this on your laptop:

https://localhost:12087

A couple details that trip people up:

127.0.0.1:2087 means “from the server itself, connect to WHM on loopback.” This works as long as WHM is reachable on the server (it usually is for cPanel/WHM).
Your browser may warn about a certificate mismatch because the cert is for the server hostname, not localhost. To avoid that, use the server hostname. Then map it to 127.0.0.1 in your /etc/hosts while the tunnel is up.

Quick diagnostic: if the browser can’t connect, keep the SSH session open. Then test the port from the server:

sudo ss -lntp | grep 2087
curl -kI https://127.0.0.1:2087/

Step 3: Tunnel multiple hosting ports in one SSH session

For daily admin work, it’s usually easier to open one SSH connection. Then forward the ports you use most often:

ssh \
  -L 12087:127.0.0.1:2087 \
  -L 12083:127.0.0.1:2083 \
  -L 12096:127.0.0.1:2096 \
  admin@203.0.113.10

Then use:

https://localhost:12087 (WHM)
https://localhost:12083 (cPanel)
https://localhost:12096 (webmail)

This is a practical way to keep panels available to you while you remove them from the public internet.

Step 4: Make the tunnel more reliable (no remote shell, keep-alives)

If you don’t need an interactive shell, add -N (no command) and -T (no TTY):

ssh -NT \
  -L 12087:127.0.0.1:2087 \
  -L 12083:127.0.0.1:2083 \
  admin@203.0.113.10

On unreliable networks, keep the tunnel alive with client-side settings.

Add this to ~/.ssh/config on your laptop:

Host hostmycode-vps-admin
  HostName 203.0.113.10
  User admin
  ServerAliveInterval 30
  ServerAliveCountMax 3
  TCPKeepAlive yes

Then connect with a short command:

ssh -NT \
  -L 12087:127.0.0.1:2087 \
  -L 12083:127.0.0.1:2083 \
  hostmycode-vps-admin

Step 5: Use a jump host when SSH shouldn’t be public

Some teams don’t want production servers directly reachable, even over SSH.

In that setup, put a small “bastion” VPS in front. Then hop through it with -J.

Example topology

Bastion (public): 198.51.100.20
Production server (private): 10.10.0.10

ssh -NT \
  -J bastionuser@198.51.100.20 \
  -L 12087:127.0.0.1:2087 \
  produser@10.10.0.10

This keeps production SSH off the public internet while preserving full admin access.

If you want a dedicated guide for this pattern, HostMyCode’s jump host walkthrough is here: SSH jump host setup tutorial.

Step 6: Lock down the server so the tunnel is actually worth it

Port forwarding pays off when you also remove public exposure.

Make changes in a safe order so you don’t lock yourself out mid-change.

Confirm the tunnel works (your localhost URLs load).
Restrict public access to the admin service (firewall and/or service binding).
Retest from an external network to ensure the port is closed, and confirm the tunnel still works.

Option A (recommended): bind the service to loopback/private IP

For custom admin apps, bind to 127.0.0.1 in the service config.

Example for a generic app listening on 0.0.0.0:9000:

# Change to loopback-only
listen 127.0.0.1:9000

Option B: firewall drop for the admin port (keep SSH only)

On systems using firewalld (Alma/Rocky):

sudo firewall-cmd --permanent --remove-port=2087/tcp
sudo firewall-cmd --permanent --remove-port=2083/tcp
sudo firewall-cmd --reload

On Debian/Ubuntu with nftables, you’ll typically manage via your ruleset or a front-end.

If you want a port exposure checklist that won’t break email/DNS/web, use this guide: firewall audit tutorial.

Step 7: Use remote port forwarding for controlled “reverse access” (optional)

Remote forwarding (-R) exposes a port on the server that points back to your workstation.

A hosting use case: you’re migrating a site and need the server to reach a temporary service on your laptop (rare). Another use case is testing webhook callbacks during a short, controlled debugging window.

Example: expose 127.0.0.1:18080 on the server and forward it to your laptop’s localhost:8080:

ssh -NT -R 127.0.0.1:18080:127.0.0.1:8080 admin@203.0.113.10

Keep it loopback-only on the server (127.0.0.1:18080), or you may accidentally expose your laptop service.

If you truly need wider exposure, put explicit controls around it and keep the window short.

Treat it like an incident change, not a standing configuration.

Step 8: Browser and certificate handling (avoid bad habits)

The cleanest workflow is to browse to the service using its real hostname. The traffic still routes through localhost via your tunnel.

Option: hosts file mapping (temporary)

On macOS/Linux edit /etc/hosts; on Windows edit C:\Windows\System32\drivers\etc\hosts (run as Administrator):

127.0.0.1   whm.example.com

Then open https://whm.example.com:12087.

TLS now matches (assuming WHM is configured with a certificate for whm.example.com).

If you’re struggling with TLS automation on a VPS, see SSL certificate deployment tutorial.

Step 9: Common failures and fast fixes

“Channel open failed: administratively prohibited”
Your server’s sshd blocks forwarding. Check /etc/ssh/sshd_config for AllowTcpForwarding and reload SSH.
Browser connects, then instantly resets
You forwarded to the wrong destination port or the service only listens on a different interface. Confirm with ss -lntp on the server.
Port already in use on your laptop
Pick a different local port (e.g. 12087 → 22087). Local ports only need to be free on your machine.
SSH disconnects every few minutes
Add ServerAliveInterval and verify your network isn’t killing idle sessions (hotel Wi‑Fi does this).
cPanel/WHM pages partially load
Some assets may redirect to the default hostname/port. Use the hosts-file method and ensure WHM’s hostname is correct.

Operational checklist: use tunnels safely in real hosting work

Forward only what you need. Don’t accumulate a “tunnel zoo” of ports you never use.
Prefer loopback binding for admin services. Firewalls drift; bind addresses don’t.
Log SSH access and alert on anomalies. A tunnel is still SSH.
For teams: avoid sharing one key. Give each admin an account and key, then remove promptly.
During migrations: tunnel panels on the destination server before DNS cutover so you can verify settings privately.

Summary: keep admin access, drop public exposure

SSH tunneling won’t compensate for weak credentials or sloppy access control.

It does give you a simple win: you can close public admin ports without breaking your workflow.

If you run cPanel/WHM, webmail, or custom dashboards, this pattern is one of the quickest security improvements you can implement in an afternoon.

If you want a VPS sized for control panels and daily admin work, start with a HostMyCode VPS.

If you’d rather have patching and baseline hardening handled for you, choose managed VPS hosting and keep your focus on websites and clients.

Running cPanel/WHM, webmail, or private admin tools? Put them behind SSH tunnels and keep your public ports minimal. HostMyCode offers VPS plans for hands-on admins and managed VPS hosting if you want secure defaults, updates, and operational guardrails handled for you.

FAQ

Should I tunnel cPanel/WHM even if it already uses HTTPS?

Yes, if you don’t need public access. HTTPS encrypts traffic, but it doesn’t reduce scanning, login attempts, or exploitation of panel-side bugs. Tunneling lets you remove public reachability.

Do I need to open extra firewall ports for SSH port forwarding?

No. That’s the point. You only need SSH reachable (ideally restricted by IP, MFA, and keys). The forwarded ports are local to your machine.

Is port forwarding safe for teams?

It can be, if you use individual user accounts and SSH keys per admin. Avoid shared credentials. Pair it with monitoring so you can trace who accessed what and when.

What’s better: tunneling or a VPN?

For a few admin ports, tunnels are faster to deploy and easier to audit. For broader internal access across many services, a VPN can be cleaner. Many hosting teams run both, depending on the job.

Can I use this during a hosting migration?

Yes. Tunneling is excellent for verifying destination server settings before DNS changes. Pair it with a step-by-step move plan like this hosting migration checklist.