eitri is the only thing that can dial an eitri guest: SSHArgv never emits ssh_config #94

New issue

Open

opened 2026-08-22 16:10:43 +00:00 by a73x · 0 comments

a73x commented

2026-08-22 16:10:43 +00:00

(Migrated from git.a73x.sh)

eitri is the only thing that can dial an eitri guest. SSHArgv
(internal/cli/sshcmd.go:34) builds a complete system-ssh argv — gate hop as an
explicit ProxyCommand, pinned CA known_hosts, strict checking, the namespaced
. connect name — and then execs it. Every input is already resolved
there; none of it is ever emitted.

So eitri ssh <vm> [remote command] works, and nothing else does. rsync, scp,
sftp, git-over-ssh, sshfs, VS Code Remote and any agent harness that shells out
to ssh user@host cannot reach a guest, because they build their own argv and
have no way to learn the gate hop.

Proposal: teach eitri to emit the same connection as ssh_config — a Host
block with the ProxyCommand, UserKnownHostsFile, IdentityFile and StrictHostKeyChecking
that SSHArgv already computes — so the existing tools work unmodified. Shape is
open: eitri ssh --print-config, an Include-able file eitri init writes, or
both. SSHArgv stays the single source of the argv shape; the emitter is a second
rendering of the same resolved Env, and the existing table tests should cover
both renderings together so they cannot drift.

Worth a cheap spike first: rsync invokes <rsh> <host> <remote-cmd> and
GIT_SSH_COMMAND is invoked the same way, which is coincidentally the exact shape
of eitri ssh <vm> <cmd>. rsync -e "eitri ssh" and
GIT_SSH_COMMAND="eitri ssh" may already work by accident. Unverified. If they
do, that is worth documenting either way, and it does not cover scp/sftp/sshfs
or anything that parses ssh_config.

Why it matters now: this is the barrier to getting code onto a guest, and it is
not a storage problem. It blocks the durable-workspace work from being useful,
and it is what would let an external agent harness route its tools into an eitri
guest with zero eitri-specific code.

Migrated from git-collab issue 571002f452d8998d57217df7fc0be45a25d71bca.

Original author: a73x dev@a73x.sh.

eitri is the only thing that can dial an eitri guest. `SSHArgv` (internal/cli/sshcmd.go:34) builds a complete system-ssh argv — gate hop as an explicit ProxyCommand, pinned CA known_hosts, strict checking, the namespaced <tenant>.<vm> connect name — and then execs it. Every input is already resolved there; none of it is ever emitted. So `eitri ssh <vm> [remote command]` works, and nothing else does. rsync, scp, sftp, git-over-ssh, sshfs, VS Code Remote and any agent harness that shells out to `ssh user@host` cannot reach a guest, because they build their own argv and have no way to learn the gate hop. Proposal: teach eitri to emit the same connection as ssh_config — a `Host` block with the ProxyCommand, UserKnownHostsFile, IdentityFile and StrictHostKeyChecking that SSHArgv already computes — so the existing tools work unmodified. Shape is open: `eitri ssh --print-config`, an Include-able file `eitri init` writes, or both. SSHArgv stays the single source of the argv shape; the emitter is a second rendering of the same resolved Env, and the existing table tests should cover both renderings together so they cannot drift. Worth a cheap spike first: rsync invokes `<rsh> <host> <remote-cmd>` and GIT_SSH_COMMAND is invoked the same way, which is coincidentally the exact shape of `eitri ssh <vm> <cmd>`. `rsync -e "eitri ssh"` and `GIT_SSH_COMMAND="eitri ssh"` may already work by accident. Unverified. If they do, that is worth documenting either way, and it does not cover scp/sftp/sshfs or anything that parses ssh_config. Why it matters now: this is the barrier to getting code onto a guest, and it is not a storage problem. It blocks the durable-workspace work from being useful, and it is what would let an external agent harness route its tools into an eitri guest with zero eitri-specific code. --- Migrated from git-collab issue `571002f452d8998d57217df7fc0be45a25d71bca`. Original author: a73x <dev@a73x.sh>.