SSH Beyond a Plain Shell: Port Forwarding & Jump Hosts

A plain shell is only one thing SSH is good for. This chapter covers two techniques a support engineer runs into constantly: reaching a service that was deliberately never exposed directly, and connecting through a hardened gateway to internal servers you can't reach straight from the internet.

Local Port Forwarding: Reaching a Service That Isn't Exposed

This forwards your own machine's local port 5432 through the SSH connection to port 5432 as seen from the remote side — commonly its own localhost, reaching a service that's only listening internally on that server, never exposed to the outside at all. Once the tunnel is open, connecting a local client to localhost:5432 on your own machine transparently reaches the remote database.

Why Services Are Often Not Directly Exposed — And Why That's Good

A database listening only on localhost, reachable by nothing outside that one machine, is a deliberate security practice — the same reasoning Network Troubleshooting covers for firewall rules: reducing the attack surface by not exposing anything that doesn't genuinely need to be reachable from outside. SSH port forwarding is the sanctioned way to reach such a service for legitimate diagnostic work, without weakening that security posture by opening the port more broadly to make things convenient. The "obstacle" of not being directly reachable is the control working exactly as intended — tunneling through SSH works with it, not around it.

Remote Port Forwarding: The Reverse Direction

ssh -R reverses the direction — exposing a port on your own machine so the remote side can reach it. Less common for this course's own use cases than local forwarding, but worth knowing it exists: it's the right tool when a remote system needs to temporarily reach something running locally on your machine, rather than the other way around.

Jump Hosts and Bastion Hosts

Many organizations don't allow direct SSH access to internal servers from the general internet at all — instead, one hardened, carefully monitored "jump host" (or bastion host) is the only machine reachable from outside. You connect to it first, then reach the actual target from there. The modern, clean way to do this in one step:

Concentrating the exposed attack surface onto one well-monitored machine, rather than every internal server needing to individually defend itself against internet-facing attacks, is exactly the same logic behind not exposing the database port directly.

Combining Both: ProxyJump Plus Port Forwarding

One command: connect through the bastion, land on the database server, and forward its localhost-only database port to your own machine — all in a single line.

Simplifying Repeated Use With ~/.ssh/config

With this saved, ssh db-server alone does everything the full command above did.

Working Example: A Production Database, Reachable Only Through a Bastion

A diagnostic query needs to run directly against a production database that's only reachable via an internal bastion, and only listens on localhost on the database server itself:

A read-only diagnostic query, run against a database that was never directly exposed, using exactly the sanctioned path — and the tunnel explicitly closed the moment the work is done.

Hands-On Exercises