323e2c24

feat(web): the VM page hands you the command that reaches the guest

a73x   2026-08-09 19:47

feat(web): the VM page hands you the command that reaches the guest

A VM's page prints the ssh that opens a shell on it, with this plane's gate and
this VM's connect name already in it. The gate hop rides an explicit
ProxyCommand rather than -J, because a command-line -o reaches only the final
hop and both hops must verify the certificate they present — the same argv
`eitri ssh` execs, and the same one docs/ssh-access.md prints, down to the
single quotes around the known-hosts path in the nested command: the outer
shell expands it into the ProxyCommand string and ssh runs that string through
a shell of its own, so a $HOME with a space in it needs quoting at both layers.
docs/ssh-access.md was missing the inner pair and now carries it, with the
sentence that says why.

A VM's page is its own facts; the way in is one line under them. "Connect"
opens onto three tabs — the one command, the ~/.ssh/config stanzas, and what
both of them need — and the command leads, because it is the shortest path
from this page to a shell. Closed is the default: anyone already set up needs
none of it.

The second tab is the ~/.ssh/config stanzas that make the whole thing
`ssh <tenant>.<vm>`: one for the gate, one for this VM, both exact names. The
gate's stanza is its own name because ssh verifies the certificate against the
name it dialed and that certificate carries exactly one principal; the VM's is
this VM alone, since a `<tenant>.*` pattern would quietly claim every name in
the tenant — the gate's included — and every VM's page prints its own stanza
anyway.

Then what both of them need, stated rather than assumed: eitri's host CA pinned
in a file of its own, and a certificate on your key from a CA this tenant has
registered — with the principal `ubuntu`, which a guest matches against the
login user and refuses anything else of. The CA link goes to the settings page
that holds them.

The strip is a real one. It is a single stop on the tab key, the arrows and
Home/End move within it, and each panel is named by the tab that selects it,
so the recipe reads the same to a screen reader as it does on the page. The recipes appear for a settled VM only: one still being
created may not have a signed host certificate yet, and a failed one has
nothing listening.

GET /api/v1/me carries the gate address, host:port, the value EITRI_GATE takes.
A connect name is half identity and half plane and no caller needs one without
the other, so both halves ride the response the console already fetches before
it renders. The host part is the gate's host-certificate principal and nothing
else, because any other spelling of the same machine is a hard verification
failure by design — and where the plane has no such name, it publishes none:
a wildcard bind says which interfaces to accept on, not what to call the
machine, and `localhost` is true of the plane's own box and false everywhere a
user might read it. A plane that publishes no gate gets no recipe.