vscode: SSH Remote fails to connect
Does this issue occur when all extensions are disabled?: Yes/No (Not applicable, ssh remote is an extension too)
Version: 1.61.0-insider (user setup) Commit: bb9491d9f2c65510226dcc920a6efbf6501d5943 Date: 2021-09-07T05:17:08.586Z Electron: 13.1.8 Chrome: 91.0.4472.164 Node.js: 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0.22000
Steps to Reproduce:
- Update to latest insiders build
- Connect to a SSH Remote Host
Attempts to fix the issue:
- Removing the vscode server from the SSH Host manually
- Rebooting the SSH Host
Works fine:
- Stable channel
- Yesterday’s insider build
Details in the output console:
[09:50:42.559] Log Level: 2
[09:50:42.572] remote-ssh@0.65.7
[09:50:42.572] win32 x64
[09:50:42.712] SSH Resolver called for "ssh-remote+taris", attempt 1
[09:50:42.713] "remote.SSH.useLocalServer": false
[09:50:42.714] "remote.SSH.showLoginTerminal": true
[09:50:42.714] "remote.SSH.remotePlatform": {"taris":"linux"}
[09:50:42.715] "remote.SSH.path": undefined
[09:50:42.715] "remote.SSH.configFile": undefined
[09:50:42.716] "remote.SSH.useFlock": true
[09:50:42.717] "remote.SSH.lockfilesInTmp": false
[09:50:42.717] "remote.SSH.localServerDownload": auto
[09:50:42.718] "remote.SSH.remoteServerListenOnSocket": false
[09:50:42.718] "remote.SSH.showLoginTerminal": true
[09:50:42.719] "remote.SSH.defaultExtensions": []
[09:50:42.719] "remote.SSH.loglevel": 2
[09:50:42.720] SSH Resolver called for host: taris
[09:50:42.720] Setting up SSH remote "taris"
[09:50:42.731] Using commit id "bb9491d9f2c65510226dcc920a6efbf6501d5943" and quality "insider" for server
[09:50:42.739] Install and start server if needed
[09:50:42.746] Checking ssh with "ssh -V"
[09:50:42.957] > O
[09:50:42.957] > penSSH_for_Windows_8.1p1, LibreSSL 3.0.2
[09:50:42.994] Running script with connection command: ssh -T -D 54394 taris bash
[09:50:42.997] Terminal shell path: C:\WINDOWS\System32\cmd.exe
[09:51:00.003] Resolver error: Error: Connecting with SSH timed out
at Function.Timeout (c:\Users\alexi\.vscode-insiders\extensions\ms-vscode-remote.remote-ssh-0.65.7\out\extension.js:1:64785)
at Timeout._onTimeout (c:\Users\alexi\.vscode-insiders\extensions\ms-vscode-remote.remote-ssh-0.65.7\out\extension.js:1:413911)
at listOnTimeout (internal/timers.js:554:17)
at processTimers (internal/timers.js:497:7)
[09:51:00.021] ------
Still happening on:
- 34861b8c8aa76b517f203743ad5b5d72ef5fcd81 (2021-09-08T05:17:18.073Z)
- df115e761ae11cf87ca569ca1824b7257099553a (2021-09-08T17:51:26.439Z)
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 26
- Comments: 40 (9 by maintainers)
Commits related to this issue
- Don't await profiles for custom ptys, ensure createTerminal returns Fixes #132519 Fixes microsoft/vscode-remote-release#5556 — committed to microsoft/vscode by Tyriar 3 years ago
- Ensure local terminals can launch before available profiles are ready Fixes #132519 Fixes microsoft/vscode-remote-release#5556 — committed to microsoft/vscode by Tyriar 3 years ago
Another workaround, if you have to use Insiders: set
"remote.SSH.useLocalServer": true
(this has to be set explicitly in your settings.json file, even if the checkbox is checked).This setting may cause other issues on Windows. It’s the default on other platforms but not windows
The latest insiders has the fix and it works for me.
Current bug report ticket: #133436
No offense, but why are “40 students” using what’s effectively a nightly build instead of a stable release?
(but I agree, this should be fixed ASAP, it’s annoying to have the “update available” indicator there - I always feel tempted to click it)
Sorry for the trouble, I’m looking into this now. Please use the stable build in the meantime
same issue here: latest release for windows is broken again 😐
It’s been broken for days, I guess it’s time to abandon insider releases, since there is no easy and convenient way to just grab a older working release.
You’r right; my fault; is already solved
confirmed! 👍🎉
It gets you going but it breaks a lot of stuff, like SSH agent (including agent forwarding to git or anything else), looking forward to the fix!
As a workaround I copied my installation directory from another computer where I hadn’t installed the update yet. At least I can work that way…