SSH Cheat Sheet: port forwarding patterns (local, reverse, Unix sockets) for reaching services that should stay off the public internet, plus how authentication actually works when a jump host sits between you and the target.
Local Port Forwarding (-L)
Forward a local port to a destination reachable from machine
ssh -L 1234:host:9876 root@machine -NnT localhost:1234 on your laptop becomes a secure entry point to host:9876 as seen from machine. Typical uses: local DB GUI → remote database, browser → internal admin UI, local dev tools → internal API.
Reverse Port Forwarding (-R)
Forward a remote port back to a service on your local machine
ssh -R 1234:localhost:9876 root@machine -NnT machine:1234 becomes an entry point on the remote side; connections to it are forwarded back to your local localhost:9876. Typical uses: webhooks/callbacks into a local dev server, remote debugging back into a local IDE, sharing a local prototype with a remote teammate.
Forwarded ports usually bind to the remote's own localhost. For LAN-wide access, combine -R 0.0.0.0:1234:localhost:9876 with GatewayPorts yes in the remote sshd config.
Tunnel to a Unix Domain Socket
Forward a local TCP port to a Unix socket on machine (common for MySQL/MariaDB bound to socket-only access)
ssh -L 1234:/var/run/service.sock root@machine -NnT Example: Local MySQL Port
Forward local 3307 to MySQL listening on machine's 127.0.0.1:3306
ssh -L 3307:127.0.0.1:3306 root@machine -NnT … or forward to a MySQL Unix socket on machine instead
ssh -L 1234:/var/run/mysql.sock root@machine -NnT Connect locally as if MySQL were on your own machine
mysql -h 127.0.0.1 -P 3307 -u youruser -p Use 127.0.0.1 instead of localhost — some clients otherwise prefer a local socket over TCP.
Flags & Safety Options
-N no remote command, -n stdin from /dev/null, -T no pseudo-terminal — the standard combination for tunnel-only connections
ssh ... -NnT Fail fast if a forward can't be established, keep long-lived tunnels alive over flaky links
ssh -L 3307:127.0.0.1:3306 root@machine -NnT \
-o ExitOnForwardFailure=yes \
-o ServerAliveInterval=30 -o ServerAliveCountMax=3 Add -v / -vv to debug tunnel problems.
Quick Mental Model
-L (Local): "I connect locally → forwarded to a remote destination via machine."
-R (Reverse): "Remote connects on machine → forwarded back to my local machine."
Unix socket forwarding: "Expose a remote socket on machine as a local TCP port."
Jump Hosts & ProxyJump
Connect straight to a target host through a jump server
ssh -J jumpuser@jumpserver targetuser@targetserver
Does the jump server authenticate you to the target? No — not with ProxyJump. It only forwards the TCP connection; authentication against the target is still performed by your local machine.
Local machine ── Key A ──> Jump server
Local machine ── Key B ──> Target server
Connection passes through the jump server Your public jump key lives in ~jumpuser/.ssh/authorized_keys on the jump server, your public target key lives in ~targetuser/.ssh/authorized_keys on the target — both private keys stay exclusively on your local machine.
Only if you first log into the jump server and run ssh target from there does the jump server itself need a matching private key or a forwarded SSH agent. With ssh -J / ProxyJump, neither is required.
You may reuse the same local key for both servers. The same public key then sits on jump server and target — not because the jump server authenticates to the target, but because your local client authenticates to both independently.
Practical Security Notes
Local forwards bind to 127.0.0.1 by default — only you can reach them on your own machine. For LAN access use -L 0.0.0.0:1234:host:9876, carefully.
Avoid SSHing as root unless necessary; a dedicated, least-privilege user is usually better.
For long-running tunnels, use ~/.ssh/config entries and autossh for automatic reconnects.