vmssh handshakeError blames the CA set for every 'unable to authenticate' #115
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
[claude 2026-09-02] internal/server/vmssh/vmssh.go handshakeError turns any ssh error containing "unable to authenticate" into "it trusts the CA set it was created with, and that set does not include the CA you delegated with". On forge-1 that was false — vm_info showed the delegating CA in trusted_cas; the real cause was the user's cloud-init having replaced the write_files that install the trust (see the cloud-init merge issue). The message sent the operator to re-delegate instead of at the guest.
Fix direction: only claim the CA-set mismatch when the server can see it (compare the delegation's CA fingerprint against the VM's frozen trusted_cas before dialling); otherwise say "the guest refused the certificate" and list the things that make a guest do that: trust file missing/overwritten, sshd drop-in absent, clock skew beyond the cert window, principal mismatch. Unit-testable: handshakeError(vm, err, delegatedCA, trustedCAs).
Migrated from git-collab issue
fb5d62c5fd09067f5d03d8aaab5f56de9ac6ea70.Original author: a73x dev@a73x.sh.
Close reason: merged in patch
3497ecbd[claude 2026-09-02] Picking this up on branch fix/* in a worktree; Opus subagent implements under TDD, boot gate before merge.