Repository navigation
feat(ssh): report and optionally pin verified discovery-to-delivery host identity #183
Description
Reddit feedback
A reader asked whether SSH discovery and delivery used the same host and key, because aliases or route changes can make failures confusing. Source: https://www.reddit.com/r/ClaudeCode/comments/1wotkse/i_built_sessionpeer_to_hand_off_messages_between/
Current v1.0.0 boundary
Results report a canonical host and original SSH alias, and MagicDNS routing preserves HostKeyAlias (see session_peer_core/output.py and docs/cli-reference.md). Separate list and send invocations are not cryptographically bound to the same verified host key.
Proposed work
- Define safe diagnostic fields for the effective SSH destination, alias, key lookup identity, and verified host-key fingerprint (or a stable, nonsecret equivalent), without leaking raw SSH config or credentials.
- Explore an explicit precondition so a send can refuse if the verified SSH host identity differs from the prior discovery, including alias/HostName changes and key rotation.
- Keep host-key verification enabled; never silently accept a changed key or turn a diagnostic into an authentication bypass.
- Tests cover same host/key, changed key, alias canonicalization, and separate list/send races. Keep session-generation pinning a separate requirement.
No claim that current host metadata proves key continuity.
Activity
abruption commentedon Oct 9, 2026
Final acceptance — 2026-10-09: closing as completed for the documented v1.1.0 supported scope, implemented by #287.
Opt-in POSIX
--ssh-identity/--require-ssh-host-keyuse the actual dispatch connection, with strict verification and multiplex reuse disabled. Taggedtests/core/test_ssh_identity.pyandtest_ssh_identity_handshake.pycover matching and changed keys, including zero authentication/exec on mismatch; existing SSH tests cover alias/canonical routing. Actual-connection enforcement avoids trusting a separate discovery probe; no dedicated combined live list/send-race test is claimed.Support is ordinary Ed25519/RSA/ECDSA public keys on POSIX. Windows, host certificates, security-key algorithms and custom KnownHostsCommand are not supported. A host key is not unique machine/account/session identity or ACK; fixtures are not real remote-host/native-agent acceptance. Tagged CLI documentation still uses historical development wording, so the published release record is the current availability reference; no runtime absence is inferred from that wording.
Release evidence: v1.1.0, source
8ca77cf31254c8287a2593fe484bb30a7dba2727; exact integrated-main CI and PyPI publication/verification succeeded. Final acceptance rechecked tagged code/tests/docs and merged PR evidence; this final accounting did not rerun tests or perform new live messages, native wake, installations or operations.