Add port forwarding: local, remote and dynamic, per terminal session
ci / build and test (push) Successful in 3m43s
ci / api image (push) Canceled after 0s
ci / android head (push) Canceled after 4m6s
ci / desktop nightly (push) Canceled after 21s

A host can now carry port forwards (-L, -R, -D), saved inside its
encrypted payload as RelayTicketRequest.PortForwardId already assumed,
so they sync and merge per forward like tags and pinned paths. The host
schema moves to version 8 only for hosts that carry forwards.

ISshConnection gains StartForwardAsync over SSH.NET's forwarded ports.
Every listener binds loopback and there is no bind-address field: a
forward is something any member of a shared keychain can edit. A remote
forward's target is resolved here, IPv4 first, rather than by SSH.NET's
constructor, which takes the first DNS answer and can send ::1.

Forwards start with every terminal opened to the host and stop with its
connection; a reconnect starts them again. The session sidebar lists
them with state, failure reason and an on/off switch, the status bar
counts the listening ones, and the host editor and detail pane gain a
PORT FORWARDS section. A forward that cannot start fails alone.

The phone does not start forwards yet: it has no surface showing what
is listening, and its More screen now says so. No byte counts, since
SSH.NET keeps none.
This commit is contained in:
jaap-jan committed 2026-09-28 20:47:02 +02:00
1 parent c8848ec1e3
commit f05deb4fbc
36 files changed
+2776 -42

No files matched your search

+31 -5
View File
@@ -44,7 +44,7 @@ Three consequences worth knowing before you read further:
The reasoning behind each major decision is recorded in [`docs/adr/`](docs/adr/), starting with
[the E2EE trust model](docs/adr/0001-e2ee-trust-model.md).
The desktop client's interface was built from a design covering more product than exists yet — file
The desktop client's interface was built from a design covering more product than existed at the time — file
transfer, teams, saved snippets, port forwarding. Everything that design asked for and this build has not
got is written down in [`docs/design-import-gaps.md`](docs/design-import-gaps.md), with the layer each
piece would land in and what the interface shows in its place. Nothing was rendered with invented data to
@@ -426,6 +426,31 @@ What is not here: transferring a directory, dragging between the panes, and rout
bastion — the last needs jump hosts the connection layer has not got. All three are in
[`docs/design-import-gaps.md`](docs/design-import-gaps.md).
### Forwarding ports
A host can carry **port forwards**, added under PORT FORWARDS in its editor, in the three kinds OpenSSH has:
**local** (`-L`, a port here reaching a machine the remote can see), **remote** (`-R`, a port on the remote
reaching back to one this machine can see) and **dynamic** (`-D`, a SOCKS proxy here whose connections leave
from the remote). They are saved in the host's encrypted payload, so they sync, merge and are shared with the
host, and they start with every terminal opened to it. The session sidebar lists them under FORWARDS with the
state of each, and the status bar counts the ones listening.
Three things about them are worth expecting rather than discovering.
**Everything listens on localhost, and there is no setting for it.** A forward is a field any member of a
shared keychain can fill in, and one bound to every interface would hand the remote's network to anybody who
can reach your machine for as long as the terminal is open. A remote forward asks the remote for its loopback
too; whether the remote honours that is its own `GatewayPorts`.
**A forward lives as long as its terminal.** It runs over that tab's connection, so closing the tab, losing
the connection or reconnecting stops it — a reconnect starts the host's forwards again on the new session. A
second tab to the same host runs the same forwards, and they fail there because the ports are taken; the row
says so, and the terminal is unaffected. Any row can be switched off and on while its session is up.
**No byte counts**, which the design draws: SSH.NET keeps none, so a number there would be invented. The
phone does not start forwards yet, because it has nowhere to show you they are running; its More screen says
so.
### Sharing a vault
**VAULTS** in the nav rail lists every vault you can see, makes new ones, adds people to one,
@@ -710,10 +735,11 @@ What it does *not* yet do is use the extra width inside a screen: the host list
size. Two columns needs the row model to change — the list is headings and hosts in one sequence, and a
heading has to span — which is shared with the desktop and is its own piece of work.
**Port forwarding is not built anywhere**, and the phone's More screen says so in a paragraph rather than
leaving a gap. The v2 design draws a whole screen for it; nothing in the SSH layer forwards anything, so
every control on that screen would have had no effect. See
[`docs/design-import-gaps.md`](docs/design-import-gaps.md).
**Port forwarding runs on the desktop and not here yet**, and the phone's More screen says so in a paragraph
rather than leaving a gap. The v2 design draws a whole screen for it. The forwarding itself is shared code and
would run here unchanged, but this head has no surface that lists what is listening, and a phone opening
listeners it never shows you is worse than one that opens none. See
[Forwarding ports](#forwarding-ports) and [`docs/design-import-gaps.md`](docs/design-import-gaps.md).
It is deliberately **not** in `DodoSSH.slnx`. Putting it there would make the `android` workload and a full
Android SDK a prerequisite of `dotnet build DodoSSH.slnx` for everybody; it has its own CI job instead, which