Remote-SSH 0.122.0 hangs at "Connecting with SSH timed out" on Windows host with PowerShell DefaultShell when useLocalServer=false

[levilindsey]

Environment

• VS Code: 1.117.0
• Remote-SSH: 0.122.0
• Local OS: Windows 11
• Remote OS: Windows 11 (Win32-OpenSSH server, OpenSSH_for_Windows_9.5p2)
• Remote DefaultShell: powershell.exe (Microsoft's recommended setting for Remote-SSH on Windows hosts)
• Remote DefaultShellCommandOption: -c

Symptom

Connecting from Windows → Windows times out with Resolver error: Error: Connecting with SSH timed out after connectTimeout seconds. The Remote-SSH log shows the bootstrap script being generated, then no further activity until the timeout fires:

[...] Running script with connection command: "C:\Windows\System32\OpenSSH\ssh.exe" -T -D <port> <host> powershell
[...] Generated SSH command: 'type "...sh" | "ssh.exe" -T -D <port> <host> powershell'
[...] Using connect timeout of 122 seconds
[...] Terminal shell path: C:\Windows\System32\cmd.exe
[...122s later...]
[...] Resolver error: Error: Connecting with SSH timed out

No stderr> output is logged in this code path, so the failure is silent.

What's NOT the cause

Verified by running the exact command VS Code generated (type <bootstrap>.sh | ssh -T -D <port> <host> powershell) from cmd.exe on the same client, with the same registry settings on the host. The bootstrap runs to completion: emits all expected markers (<uuid>: running, pauseLog, resumeLog, start, end), listeningOn==<port>==, serverStartTime==<ms>==, etc. So:

• SSH connectivity works.
• Authentication works.
• The remote PowerShell wrapping (pwsh -c powershell → child PowerShell reading from stdin) works.
• The bootstrap script's logic works.

The hang is specific to how Remote-SSH's useLocalServer=false code path spawns ssh and reads stdout via Node.js.

Workaround

Setting "remote.SSH.useLocalServer": true makes it work immediately. The local-server code path uses Git's bundled OpenSSH (10.0p2) when found and a different stdio handling, and connects in ~5 seconds.

Other settings tried that did not fix it on their own: useExecServer: false, useFlock: false, connectTimeout: 120, DefaultShellCommandOption: -c, switching DefaultShell to pwsh 7.

Suggested investigation area

The Node.js child_process.spawn path used when useLocalServer=false appears to have a stdio handling regression specific to interactive PowerShell on the remote (banner + prompts before the script's first marker). The marker bytes are emitted by the remote, but VS Code's stdout reader doesn't appear to act on them.

[vimholic]

Same issue here — confirming the workaround works.

Environment:

• VS Code 1.117.0, Remote-SSH 0.122.0
• Local: Windows 11 with WSL Ubuntu, inbox OpenSSH client 9.5p2
• Remote: Windows 11, Win32-OpenSSH-GitHub 10.0p2 server (port 2222)
• DefaultShell: cmd.exe (default, no registry override)

Symptom: Identical to OP — Connecting with SSH timed out after 122s. The Generated SSH command runs to completion when executed manually from cmd.exe (type bootstrap.sh | ssh -T -D <port> <host> powershell) and emits all expected markers (listeningOn==<port>==, serverStartTime==<ms>==, the per-stage <uuid>: ... markers, etc.). The remote PowerShell process spawns and the bootstrap completes — VS Code's stdout reader simply receives nothing.

Spent 6+ hours debugging the wrong layers (zombie command-shell process cleanup, attempted DefaultShell=wrapper.cmd to force powershell -NonInteractive -Command -, toggling useExecServer) — none of it was the root cause. The remote side was never the issue.

Workaround verified: Adding "remote.SSH.useLocalServer": true to settings.json resolved it instantly. Connected in ~10 seconds (vs 122s timeout). My local has Git for Windows installed, so it picked up the bundled C:\Program Files\Git\usr\bin\ssh.exe (OpenSSH 9.9p1).

Side notes for anyone hitting this:

• useExecServer=true did not fix it on its own — same failure mode but at ~90s instead of 122s, with Got bad result from install script and an empty Install terminal quit with output: line in the log.
• The 4-28 timing of OP's report aligns with our environment: this started failing for us on the same date when VS Code 1.117.0 / Remote-SSH 0.122.0 rolled out. Previous versions (or the cached-commit fallback path) worked fine.

Suggestion: even just a one-liner in the docs that useLocalServer=true is the recommended setting for Windows→Windows would save a lot of misdirected debugging.