Advanced SSH: jump hosts, tunnels, and power-user tricks

Basic SSH — log in, run a command — is already a superpower. But under the hood SSH is less a "remote login tool" and more a secure tunnel you can bend in surprising ways: reach servers with no public address, pull a database port to your laptop, browse the web through a remote machine, all over one encrypted connection. This is the guide to the tricks that make seasoned engineers look like wizards. It assumes you're comfortable with the SSH basics; if not, start there.

First: a config file that does the heavy lifting

Before any tricks, the single biggest quality-of-life upgrade is ~/.ssh/config. Instead of typing long host strings, you describe each server once:

Host prod
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/id_ed25519

Now ssh prod does everything. Every flag below can live in this file too, so a gnarly one-liner becomes a clean alias you'll actually remember. Most "advanced SSH" is really just knowing what to put here.

Jump hosts: reaching servers you can't reach

Production databases and internal servers usually have no public address on purpose — you can't reach their port from the internet, and a firewall blocks the rest. The way in is a bastion (or "jump host"): one hardened, internet-facing server that's allowed to talk to the private ones. You SSH through it.

The old way was to log into the bastion, then SSH again from there. The modern way is one command:

ssh -J bastion.example.com you@private-server

The -J flag (ProxyJump) chains the hops automatically — your connection to the private server is tunneled through the bastion, end to end encrypted, without your keys ever sitting on the bastion. In config form:

Host private-server
  ProxyJump bastion.example.com

You can even chain several jumps with commas. This is "shell jumping," and it's how teams reach locked-down infrastructure safely.

Port forwarding: tunnels through SSH

This is the part that feels like magic. SSH can carry other traffic inside its encrypted connection. There are three directions:

Type	Flag	What it does
Local	`-L`	Bring a remote port to your machine
Remote	`-R`	Expose a local port on the remote machine
Dynamic	`-D`	Turn the server into a SOCKS proxy

Local forwarding (`-L`)

The everyday hero. Say a database listens on the server but isn't exposed to the internet:

ssh -L 5432:localhost:5432 you@server

Now localhost:5432 on your laptop is secretly the database on the server. Point your GUI at localhost and you're querying production through an encrypted tunnel — no database port ever opened to the world.

Remote forwarding (`-R`)

The reverse: expose something running on your machine to the remote side.

ssh -R 8080:localhost:3000 you@server

Now localhost:8080 on the server reaches the app running on your laptop's port 3000 — handy for showing a colleague a work-in-progress, or letting a server reach back to a dev machine.

Dynamic / SOCKS forwarding (`-D`)

Turn the server into a personal proxy:

ssh -D 1080 you@server

Point your browser's SOCKS proxy at localhost:1080 and your traffic exits from the server's network. Useful for testing how a site looks from another region, or reaching anything only that network can see.

Agent forwarding (and its one caveat)

Need your keys available on the server you've jumped to — say, to git pull from a private repo? Agent forwarding (-A) lets the remote machine use your local keys without copying them there:

ssh -A you@server

The caveat: anyone with root on that server can use your forwarded agent while you're connected. Only forward to hosts you trust, and prefer ProxyJump over agent forwarding when you just need to reach past a bastion.

Speed: connection multiplexing

If you SSH to the same host repeatedly, multiplexing reuses one connection so the second, third, and tenth feel instant. In ~/.ssh/config:

Host *
  ControlMaster auto
  ControlPath ~/.ssh/cm-%r@%h:%p
  ControlPersist 10m

Now repeated commands and tools that shell out over SSH (deploys, file syncs) skip the handshake entirely.

A hardening checklist for servers

If you run the servers, lock SSH down:

Do this	Why
Disable password auth	Kills brute-force attacks against port 22 entirely
Disable root login	Forces a named user + sudo (accountability)
Use a bastion	One audited door instead of many
Keep keys per-person	Revoke one without rotating everyone
Rate-limit / monitor port 22	Spot the constant background scanning

You can confirm what's exposed from outside with our port checker — if port 22 answers from the public internet, make sure password auth is off and a bastion is in front of anything sensitive. And since the bastion is your single door to everything behind it, keep a TCP monitor on its port 22: if that one host stops answering, you've lost access to the whole fleet, and you'll want to know first.

The bottom line

	In one line
Config file	`~/.ssh/config` turns every trick below into a one-word alias.
Jump host	`ssh -J bastion you@private` reaches servers with no public address.
Tunnels	`-L` pulls a remote port local, `-R` pushes local out, `-D` is a SOCKS proxy.
Multiplex	Reuse one connection so repeats feel instant.

The mental shift is this: SSH isn't just a login — it's a programmable, encrypted pipe you can route almost anything through. Reach private servers via a bastion, tunnel a database to your laptop, proxy a browser through another network — all without poking a single new hole in a firewall. Put the flags in your config once, and the wizardry becomes muscle memory.