SSH Explained: Keys, Tunnels, Jump Hosts, and Why They Matter

SSH is not really a door key. It’s more like a multi-tool: you can use it for a remote shell, secure copy, identity management, jump hosts, and tunnelling. SSH is introduced as the thing you use to log into a machine, and then it quietly turns into background plumbing.

What is really happening when you are SSH'ing:

1. A secure handshake between you and the server
2. An encrypted pipeline for an interactive shell.

Point 2 is what makes SSH special. Once the encryption pipe exists, one can send shells, files, ports, and even other SSH connections through it.

SSH Keys

Passwords work, and SSH supports them, but they aren’t very safe in practice.

Keys solve two problems:

• They’re hard to guess.

• They let you authenticate without sending reusable secrets across the network.

The workflow most people want:

• Generate a key.
• Put the public key on the server.
• Let your machine remember the private key securely.

How to generate a modern key

ssh-keygen -t ed25519 -C "[email protected]"

The above bash will give you two keys:

1. Private key (~/.ssh/id_ed25519): This needs to be secured.
2. Public Key (~/.ssh/id_ed25519.pub): This is safe to share.

Configure SSH config file:

Put your defaults in ~/.ssh/config:

Host prod
  HostName 203.0.113.10
  User ubuntu
  IdentityFile ~/.ssh/id_ed25519
  ServerAliveInterval 30
  ServerAliveCountMax 3

This works like a charm:

ssh prod

SSH portforwarding

Port forwarding is where SSH stops being “remote login” and starts being “secure logging.”

Say your database is only accessible from inside a private network. You can create a tunnel:

ssh -L 5432:db.internal:5432 user@bastion

Now your local machine can connect to localhost:5432, while SSH quietly carries the traffic to db.internal:5432 through the bastion host.

This is how employee access is handled: no opening database ports to the internet, no “temporary” firewall exceptions, and no copy-pasting credentials into random tools that shouldn’t have them.

Remote forwarding: expose your local service to a remote machine

Useful when you need a remote server to call something running on your laptop:

ssh -R 8080:localhost:8080 user@server

Now server:8080 forwards to your local machine’s port 8080.

Dynamic forwarding: SOCKS proxy

ssh -D 1080 user@server

Point your browser (or tool) at a SOCKS proxy on localhost:1080 and route traffic through the encrypted SSH connection.

This is not a replacement for a real VPN in enterprise environments, but it’s incredibly handy for debugging or reaching internal services in a controlled way.

Jump hosts without the pain

If production is only reachable through a bastion (as it should be), use ProxyJump:

Host bastion
  HostName bastion.example.com
  User ubuntu

Host prod
  HostName prod.internal
  User ubuntu
  ProxyJump bastion

Now:

ssh prod

SSH handles the hop automatically, and your terminal doesn’t turn into a nested Russian doll of sessions.

SSH Handshakes

If you run lots of SSH commands in a row (deploy scripts, automation, repetitive admin tasks), enable connection sharing:

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

This lets multiple SSH invocations reuse one underlying connection. Result: noticeably faster workflows, especially when latency is non-trivial.

SSH isn't just a command. It can establish trust, encrypt the channel and use the channel for everything you can.