SSH tunnels: what they are and when to use them
A tunnel sounds advanced. It isn't. It's one of the most practical things SSH does, and sshbar reduces it to a switch.
What a tunnel is
An SSH local forward makes a port on your Mac transparently connect to a service that lives on (or behind) a server you can SSH to. Open localhost:5432 on your Mac, and you're really talking to a database on a remote or private host. No terminal window, no separate VPN client.
your Mac ssh private network localhost:5432 ═════════════▶ gateway ─────────▶ db.internal:5432 bound to 127.0.0.1, so only your machine can reach it
The mental model: the thing I want is behind a server I can SSH into; the tunnel brings its port to my laptop.
When you'd use one
Your Postgres, MySQL, Redis, or RabbitMQ is bound to a private network, or only reachable from a bastion. Tunnel its port and point your local GUI or CLI at localhost:<port>.
A staging dashboard, Grafana, a router or admin panel: anything only accessible inside a cloud VPC. Tunnel it and visit http://localhost:<port> in your browser, as if you were inside that network.
An internal API, a message queue: anything you need from your laptop without exposing it to the internet.
How sshbar runs it
Add a tunnel with a name, the SSH host (from your config), a local port, and the remote host + port. Flip the switch to start it. Under the hood, sshbar runs a dedicated background process:
ssh -N -L 127.0.0.1:<local>:<remoteHost>:<remotePort> <host>
It keeps running while the menu is closed, and is cleaned up when you quit, with no leftover ssh processes. A dot shows each tunnel's status:
Per-tunnel options: