# HyperTwist reverse-SSH auth-mode mismatch incident and recovery - 2026-06-02

## Purpose

This note captures a proven failure mode in the reverse-SSH Windows lane:
transport is healthy, but non-interactive auth mode mismatch makes command
execution look hung.

## Incident signature

- tunnel listener reachable (`localhost:22022`, fallback `localhost:22023`)
- non-interactive command path fails or stalls at auth boundary
- interactive/password-backed path succeeds

## Root cause

The issue is auth-mode mismatch, not tunnel transport failure.

- batch path expected key/non-interactive auth
- available path was password-interactive

## Deterministic recovery

1. verify tunnel reachability
2. run fail-fast batch auth probe
3. confirm interactive login once
4. use bounded temporary automation if needed (`pexpect` when `sshpass`/
   `expect` are unavailable)
5. execute target Windows Unreal command after auth mode is confirmed

## Security rule

Keep credentials in sensitive runbook authorities only.
Do not replicate passwords/keys in general ops docs.

## Outcome

- reverse-SSH lane remains valid
- auth mismatch now has a deterministic diagnosis and recovery path

## Addendum - 2026-06-04

The current live lane facts now also need to be remembered alongside the auth
classification rule:

- `22022` is the active loopback-only VPS listener
- the correct bridge target is `localhost`, not the VPS public interface
- `22023` is only a fallback when explicitly re-established; it was absent in
  the latest live probe

The current live-facts companion note is:

- `C:\HyperTwist\docs\ops\HYPERTWIST_REVERSE_SSH_LIVE_CONNECTION_FACTS_2026-06-04.md`
