Same audit as konduit-public (c61664c), applied to koridor. The conclusion
is the opposite: there is no server binary and no config format, so nothing
can be documented wrongly. The source backs the README - ffi/src/ssh.rs:389
uses per-flow channel_open_direct_tcpip, with no streamlocal, remote TUN or
forwarded-tcpip anywhere in the crate. No contradictions found; the gap was
thinness.
Added docs/server-quickstart.md. The whole server story was previously one
clause in the README:
- The real requirement (AllowTcpForwarding yes), and that it is already the
OpenSSH default, so most servers need no configuration at all.
- What you do NOT need: ip_forward, masquerade rules, /dev/net/tun, root.
Anyone who has set up a VPN server before assumes all four are required.
- Keypair generation, since the user supplies the key; koridor does not
generate one for the tunnel.
- Host key trust on first connect. The connect is refused until the
fingerprint is accepted, and a later change is fatal rather than retried.
The finding that justified the work: UDP forwarding provisions itself on the
user's server on first enable - it writes ~/.koridor/udp-relay.sh, appends a
forced-command line to ~/.ssh/authorized_keys marked # koridor-udp-relay, and
requires socat (hardcoded in ffi/src/udp_relay/script.rs:12). So "No special
server-side software required" is true for TCP and false once that toggle is
on. Nothing public said so. It is off by default and idempotent, and
remove_marked_line strips only koridor's own line, leaving every other key
untouched - but a user's authorized_keys and home directory are modified
without them being told. The README now carries that caveat inline.
#k-ops/#6/#212
278cbf4fb4