Skip to main content
A tunnel is reaching a port that lives on the other side of SSH. ssh already does that with -L, -R and -D; what TYBA adds is opening, closing and seeing the tunnel without memorizing where the colons go.

​
Two tunnels, two uses

They are not the same thing, and the difference shows up daily: The host tunnel is what lets DBeaver see the same tunnel you configured here. TYBA writes the host into your ~/.ssh/config; anything that reads that file gets the tunnel for free.

​
Registering a host tunnel

The host tunnel lives in the connection form, not in the panel — the panel is the session’s. Under SSH Connections, edit (or create) the host: the Tunnels section has one row per tunnel — the kind (-L/-R/-D), the local port, and the destination. New tunnel adds a row; Save writes it. There is no intermediate “add” step: an empty row is ignored, a half-filled row warns before saving. From then on the tunnel opens on every connection to that host — through TYBA and through anything that reads ~/.ssh/config. The same -R/-D gate applies here: saving a tunnel that opens a path back into your machine asks for confirmation once, spelling out who gets to reach you.

​
The panel

In an SSH session, the tunnels icon opens the panel beside the terminal. Each tunnel shows its kind, its path and a state dot:

​
The gate: -L passes, -R and -D ask

Classification is by direction, not by parsing a command string:
  • -L (local) — you reach a port that is over there. It asks nothing: you already have a shell on that host, so this grants you no new reach.
  • -R (remote) — opens a port on the host that leads into your machine. It asks.
  • -D (dynamic) — turns your machine into a SOCKS proxy into the host’s network. It asks.
The -R/-D dialog tells you who gets to reach what — it is not an “are you sure?”. Refusing is the default, and the gate lives in the core: no screen can open a -R without your confirmation.
A tunnel that reattaches does not ask again: you already said yes once.

​
The tunnel follows the session

The session tunnel is persisted and comes back when the SSH session reattaches — Wi-Fi dropping, the laptop sleeping, quitting the app. One rule:
The tunnel belongs to the SSH session. The SSH session survives. Therefore the tunnel survives.
See Session persistence for why the session survives.

​
When the local port got taken

If something grabbed your local port while the connection was down, the tunnel does not come back quietly: it turns red, says why, and a toast reaches you even if you are in another workspace.
This is deliberate, and it is the worst case the feature exists to prevent: the terminal coming back perfect while localhost:5432 silently stops working. You would find out minutes later, debugging the wrong app.

​
Why the tunnel always shows 127.0.0.1

You will notice TYBA writes 127.0.0.1:5432 where ssh would accept just 5432. That is not verbosity. localhost resolves to two addresses: ::1 (IPv6) and 127.0.0.1 (IPv4). With a bare port, ssh binds whatever it can and reports success if it got at least one. So if some process already holds 127.0.0.1:5432, the tunnel comes up on ::1 only, ssh says it worked — and your psql localhost:5432 talks to that other process believing it is prod. With an explicit address, the same ssh fails and says why. That is what lets the panel go red instead of lying green. If you want a different listen address, type it — the field takes it. 0.0.0.0 exposes the forward to your local network.

​
On Windows

It looks the same on screen, but the mechanism underneath differs: Windows OpenSSH has no ControlMaster, so there is no ssh -O forward. There, TYBA drops the connection and brings it back with the tunnel baked in — you see the same reconnecting… as a bad Wi-Fi, and your work is intact on the other side, because the session lives on the host.
SSH has not been tested on a real Windows machine yet — only on Linux and macOS. It was built to work there; if it doesn’t, that’s a bug, and the report helps.