# HyperTwist Deferred Tailscale And OpenSSH Local Reachability Note

Date: `2026-05-31`

Status: `deferred for later setup`

## Purpose

This note records the preferred long-term local-machine reachability model for
HyperTwist development, while explicitly preserving the current short-term
choice to use reverse SSH first.

It now also serves as the reachability companion to:

- `C:\HyperTwist\docs\ops\HYPERTWIST_UNREAL_BUILD_VALIDATION_REQUIREMENT_2026-06-01.md`

That build-validation doctrine explains why this workstation reachability path
matters: Unreal C++ slices require actual Windows Unreal builds rather than
text-only closeout.

## Current decision

Use reverse SSH now.

Defer `Tailscale + OpenSSH` until a calmer setup window.

As of `2026-06-01`, the reverse-SSH Windows shell path is also verified live
for HyperTwist Unreal build validation. The current proof note is:

- `C:\HyperTwist\docs\ops\HYPERTWIST_REVERSE_SSH_WINDOWS_BUILD_LANE_VERIFICATION_2026-06-01.md`
- `C:\HyperTwist\docs\ops\HYPERTWIST_REVERSE_SSH_AUTH_MODE_MISMATCH_AND_RECOVERY_2026-06-02.md`
- `C:\HyperTwist\docs\ops\HYPERTWIST_REVERSE_SSH_LIVE_CONNECTION_FACTS_2026-06-04.md`

## Why reverse SSH fits the immediate need

Reverse SSH works well when:

- the Windows workstation can make outbound SSH connections
- direct inbound reachability to the workstation is inconvenient or blocked by
  NAT, router policy, or operator time/energy
- the immediate goal is to let the VPS reach back into the local machine
  without opening public inbound access to the workstation

## Directionality clarification

### Current VS Code Remote SSH path

The current VS Code remote-development path is:

`local Windows workstation -> outbound SSH -> VPS`

From the workstation's point of view, this is outbound.

From the VPS's point of view, this is inbound.

### Direct VPS-to-workstation SSH path

The path that is hard in the current environment is:

`VPS -> direct inbound SSH -> local Windows workstation`

That is the path that usually becomes difficult because the workstation is
behind NAT or does not have a convenient public inbound route.

### Reverse SSH path

Reverse SSH avoids the hard direct-inbound path by doing this instead:

`local Windows workstation -> outbound SSH tunnel -> VPS`

Then, after that tunnel is established, the VPS can connect back through the
reverse port on the VPS side without needing a direct public inbound path to
the workstation.

So the workstation still initiates the connection outbound first.

## Recommended temporary reverse-SSH shape

Prerequisite on Windows:

- `OpenSSH Server` installed and running locally
- local confirmation that `ssh localhost` works

Current verified tunnel from Windows to VPS:

```powershell
ssh -NT -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 -o ServerAliveCountMax=3 -R 22022:localhost:22 dev@212.227.13.220
ssh -NT -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 -o ServerAliveCountMax=3 -R 22023:localhost:22 dev@212.227.13.220
```

Then from the VPS:

```bash
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no -o StrictHostKeyChecking=accept-new -o ConnectTimeout=10 -p 22022 -l 'DESKTOP-KS3VGHU\\anthracite ace' localhost
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no -o StrictHostKeyChecking=accept-new -o ConnectTimeout=10 -p 22023 -l 'DESKTOP-KS3VGHU\\anthracite ace' localhost
```

Current live reading:

- the Windows reverse shell is intentionally loopback-only on the VPS
- `localhost:22022` is therefore the correct bridge target
- `22023` remains the documented fallback, but the latest live probe did not
  show it as active until a second tunnel is deliberately re-established

Credential details remain in the sensitive VPS runbook rather than being
duplicated here.

For a Linux-side HyperTwist AI session, the current operator-ready pickup
sequence is now also explicit in the sensitive runbook:

- stage `/home/dev/src/ScriptoriumAI/ops/ssh/scriptorium_vps_ed25519` into a
  temp runtime path
- `ssh -tt -i /tmp/scriptorium_vps_ed25519_runtime -o StrictHostKeyChecking=no dev@212.227.13.220`
- from the VPS shell, run the reverse-tunnel connect-back command above
- use the Windows password recorded only in:
  `C:\HyperTwist\docs\ops\FORGEJO_WOODPECKER_VPS_A_TO_Z_SENSITIVE_RUNBOOK_VPS_12_24_720_UBUNTU_24_04.md`

## Why Tailscale + OpenSSH remains the preferred long-term model

It remains the preferred later setup because it gives:

- stable private addressing between devices
- bidirectional reachability without per-tunnel port bookkeeping
- less fragility than a single long-lived reverse tunnel
- easier scaling if more machines are added later
- cleaner operator reasoning: private peer network first, SSH second

## Deferred later setup target

Later, when this setup is revisited:

1. install `Tailscale` on the Windows workstation and the VPS
2. join both machines to the same tailnet
3. keep `OpenSSH Server` enabled on Windows
4. use tailnet hostnames or tailnet IPs for SSH instead of a reverse tunnel

## Scope boundary

This note is intentionally isolated.

It does not change the currently active VPS runbook, auth posture, or remote
development path by itself.

It does, however, remain the current place to point when a coding session needs
the Windows machine to be reachable for required Unreal build validation.
