Latest VSC update (1.53.0) breaks ssh fs: Extension host terminated unexpectedly.

[SteveRodrigue]

I'm not sure if the issue is within ssh fs or vsc, but vsc 1.53.0 seems to break ssh fs extension.

Me and my colleagues have the same problem. Sadly, I'm not a very good developer, so I don't know exactly what to share and/or which logs could help identify the root cause of the problem.

Here is an example of an error message I get:

  ERR No file system provider found for resource 'ssh://autom1/pom.xml': ENOPRO: No file system provider found for resource 'ssh://autom1/pom.xml'
    at o.withProvider (file:///C:/Users/username/AppData/Local/Programs/Microsoft VS Code/resources/app/out/vs/workbench/workbench.desktop.main.js:618:23325)
    at async o.exists (file:///C:/Users/username/AppData/Local/Programs/Microsoft VS Code/resources/app/out/vs/workbench/workbench.desktop.main.js:618:25690)
    at async Promise.all (index 2)

[Mister905]

Also broken for me following the January 2021 (version 1.53) VS Code update. I'm on Windows 10.

[NormandoHall]

Same here

[NormandoHall]

I downgrade to 1.52.1 as a workaround, meanwhile developers fix the issue

https://code.visualstudio.com/updates/v1_52

[Mister905]

Thanks @NormandoHall - appreciate the workaround suggestion - that works for me

[SchoofsKelvin]

Which operation systems are you using? I just updated VS Code to 1.53.0 and am able to use the extension without a problem. I tried the following things:

• Adding/removing a SSH FS folder in a workspace that already has a local folder
• Adding a SSH FS folder in a brand new VS Code window (without any workspace/folder open)
• Opening a .code-workspace with a local folder and a SSH FS folder
• Opening a .code-workspace with just a SSH FS folder
• Starting a terminal in each of the above setups (and without any workspace/folder open)

I've tried it using the "Launch Extension" launch/debug config while developing the extension, and in a regular VS Code session without any debugging. I've yet have to reproduce this issue.

Possibly related: microsoft/vscode#95111 microsoft/vscode#94807 microsoft/vscode#91044

[Mister905]

Windows 10 - @SchoofsKelvin thanks for your quick response. I was receiving the error I posted above while attempting to mount a remote folder that relied on a "hop" from another remote. Oddly enough, I had no issues mounting the remote I typically use to hop from to other remotes. Seems like I am unable to connect to any remotes that rely on this intermediate hop.

[SchoofsKelvin]

Seems like I am unable to connect to any remotes that rely on this intermediate hop. @Mister905

This seems very similar to #225. Is your intermediate hop also running RHEL 6?

[Mister905]

No - the intermediate remote is Debian 4.19.152-1

[SchoofsKelvin]

Can't immediately find a cause for this, although VS Code had quite some internal version changes: https://gist.github.com/SchoofsKelvin/4de540a2ff66f5bd8c98455742fba85e/revisions

The OpenSSL changelog between 1.1.0 and 1.1.1 didn't give any indication about this issue either.

Other related issues:

• microsoft/vscode#114362 as linked to/from from/to #225
• Debian OpenSSL issues in NodeJS (similar version as shipped in VS Code) nodejs/node#27862
• Similar extension having seemingly the same issue liximomo/vscode-sftp#881
• microsoft/vscode#115818 (points at vscode-sftp at some point, while also mentioning net changes, although this should be unrelated)
• microsoft/vscode#115859 (similar to above, also pointing to vscode-sftp)

Note: This is the repository for the extension Kelvin.vscode-sshfs, not the liximomo.vscode-sftp mentioned a few times above

[SchoofsKelvin]

The underlying ssh2 library both extensions use has an issue regarding Electron v11: mscdex/ssh2#967

Can anyone with this issue install NodeJS v12.18.3 (and preferably also v12.14.1) and try using the ssh2 module? When connecting to a host on my extension, the log window (Output > SSH FS) should print [DEBUG] Final configuration: <JSON>. Unless you're using proxies/hopping, you should be able to use this straight with ssh2:

const { Client } = require('ssh2');
const client = new Client();
client.on('error', err => console.error('SSH ERROR', err));
client.on('ready', () => {
    console.log('SSH READY');
    client.exec('whoami', (err, stream) => {
      if (err) throw err;
      stream.on('close', (code, signal) => {
        console.log('Stream :: close :: code: ' + code + ', signal: ' + signal);
        client.end();
      }).on('data', (data) => {
        console.log('STDOUT: ' + data);
      }).stderr.on('data', (data) => {
        console.log('STDERR: ' + data);
      });
    });
});
client.connect(<JSON>); // Insert JSON (as a regular JS object, not as a string) from log window

[PierreMarchand20]

Same here on macOS

[GregoryCarlsonDev]

Hello, I am also having this issue after the latest update of VS Code. I went back to 1.52 and it is working. I am naïve to these things so please take my thoughts with that grain of salt, but it feels like it is having trouble connecting to the configs in settings.json. There is a second directory that gets made for the ssh drives that I add and it feels like maybe it is looking for the config settings there? No idea, just a theory. Thanks for the great extension and your hard work.

[felipemerencioOficial]

I tried to downgrade. But it also doesn't work.

I'm using windows 10.

[nokaoii]

Same here on Windows 10. Reverting to previous version of VS doesn't seem to correct the behavior. Willing to help debug or whatever if you have something to try.

[SchoofsKelvin]

This issue might be only happening for a certain set of target servers, so it'd be nice to know this info. If you have server-side SSH logs (just the part regarding connection to it through VS Code, with sensitive information censored/stripped), that might come in handy too.

Current list of known server types that had this issue:

• RHEL 6 (6.3 and 6.4, 6.10)
  • RHEL 8 apparently unaffected
• CentOS 6 and 7 (7?)
• Hostgator servers (assuming shared hosting) which use CentOS 6 and 7, RHEL derivatives
• Debian 4 (Debian 4.19.152-1)

I've been able to set up a CentOS 6.3 VM which reproduces the issue. Trying to connect to it using the extension crashes the extension host. I'll start looking into what exactly causes this (my guess is still the Electron v11 upgrade) and if there's a way to fix it on my end.

[cssjoe]

I see the same issue ("Extension host terminated unexpectedly") on Win10, VSCode1.54-insider, connecting to CentOS 6.10, where sshd logs this:

sshd[]: fatal: Read from socket failed: Connection reset by peer

I am able to connect to Ubuntu and CentOS 7 servers. It may be a cipher issue.

CE7 via PuTTY:

Doing ECDH key exchange with curve Curve25519 and hash SHA-256 (unaccelerated)

CE6 via PuTTY:

Doing Diffie-Hellman key exchange using 4096-bit modulus and hash SHA-256 (unaccelerated) with a server-supplied group

VSCode info:

Version: 1.54.0-insider (system setup)
Commit: afd102cbd2e17305a510701d7fd963ec2528e4ea
Date: 2021-02-08T05:13:57.826Z
Electron: 11.2.2
Chrome: 87.0.4280.141
Node.js: 12.18.3
V8: 8.7.220.31-electron.0
OS: Windows_NT x64 10.0.19042

[SchoofsKelvin]

It may be a cipher issue.

Kind of. The actual call that crashes NodeJS is a call to crypto.createDiffieHelman. I've tried the same call with the same arguments on my own machine (although with a different NodeJS version) and that worked fine. Looking a bit more into it, gonna see if I can pinpoint it to be Electron or something.

[SchoofsKelvin]

Narrowed it down to Electron v11, not even requiring VS Code to reproduce the crypto.createDiffieHellman issue.

I've reported it to them: electron/electron/issues/27673

[SchoofsKelvin]

The Electron team has merged the PR into their 12-x-y branch, and I assume it'll also merge into their 11-x-y branch soon. While it's still a while before it'll end up in 11.2.4 (or later) and before VS Code upgrades their Electron version, at least there's progress.

In microsoft/vscode#114362, scriptninja suggested it might be possible to configure your server to not use Diffie-Hellman, as a workaround. I'll look into whether it's possible to disable it client-side, and push a patched version of the extension to the marketplace if so.

Another duplicate issue on the VS Code repository: microsoft/vscode#116260

[SchoofsKelvin]

I added a temporary fix (598ae06) for this issue in v1.19.2 of the extension.

This fix is enabled by default, but can be disabled by adding the DF-GE flag to your sshfs.flags (a new feature also shipped in v1.19.2), e.g. "sshfs.flags": ["DF-GE"] in your settings.json.

After a bit more testing and looking at the source code of ssh2-streams, it seems that not all Diffie-Hellman kex algorithms are prone to crashing. Only the group-exchange ones that don't use the built-in groups will crash. This fix will thus disable these algorithms, diffie-hellman-group-exchange-sha256 to be exact. If you override the algorithms.kex config field, this fix will not be applied to that config.

My CentOS 6.3 test server supports diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 (enabled by default, not sure if it actually supports more), so it falls back to diffie-hellman-group14-sha1 and works.

Again: this is a temporary fix/workaround. It'd be best if Electron releases a v11 with the fix and VS Code uses that version.

[cssjoe]

@SchoofsKelvin Thank you! I tested the update and it works for me. I can now connect to CentOS 6 servers.

[SchoofsKelvin]

This is now fixed in 1.54.0-insiders, so once 1.54.0 drops, I'll push an update to auto-disable the flag on 1.54.0+.

[SchoofsKelvin]

I just released v1.19.4 of the extension, which comes with a small change regarding this issue:

• The extension will now automatically detect if we're using an affected Electron version (>=11, <11.3) and enable the flag. This also means that the extension will automatically disable this fix if it isn't necessary anymore.
• Adding DF-GE in sshfs.flags will now enable the fix instead of disabling it. Use -DF-GE or DF-GE=false instead. (this only matters for people who added the flag because they downgraded to VS Code <1.54.0 or use VSCodium or so) I just recommend removing the flag at all. There should be no need for this anymore.

If anyone knows about any VS Code spin-offs that somehow use an affected Electron v12, please say so. Then I'll look into also making the extension detect the broken v12 versions. Since VS Code itself doesn't use v12 yet, I doubt this is an issue though.

With this change, once VS Code v1.54.0 hits, the extension will automatically disable the flag and re-enable the affected algorithms. You can already see this happening now if you're using (extension version 1.19.4 and) VS Code 1.54.0-insider.

[SchoofsKelvin]

Just tested it on VS Code 1.54.1, and everything works again. The broken algorithms work again, and the extension automatically re-enabled these algorithms.

If you're still having this issue, make sure you're using version 1.54.0 or later and didn't add any special flags in sshfs.flags.