Adding WSL in Visual Studio fails with "Failed to archive sysroot [...]"

[patrikhuber]

I'm following the instructions here: https://blogs.msdn.microsoft.com/vcblog/2017/02/08/targeting-windows-subsystem-for-linux-from-visual-studio/ to the point.
When going to "Tools > Options > Cross Platform > Connection Manager", entering the details, and clicking "Connect", it results in the following error:

The log file contains the following:

liblinux.ExceptionBase: Failed to archive sysroot, command used: 'zip -r /var/tmp/sysroot_bd10b29c-e9ef-409f-94da-ad87165daa75.zip '.
at liblinux.Services.RemoteCompiler.CreateSysrootArchive()
at liblinux.Services.RemoteCompiler.DownloadSysroot()
at liblinux.Services.RemoteCompiler.CreateSysroot()
at liblinux.Services.RemoteCompiler.CreateLocalSysroot()
at Microsoft.VisualStudio.Linux.Package.Dialogs.HeaderUpdateDialog.<>c__DisplayClass17_0.b__0(Object _)

• Your Windows build number: Microsoft Windows [Version 10.0.16299.402]

[patrikhuber]

Pasting my reply here from the other repo:

Okay, this is something very sneaky: The instructions tell you to start the ssh daemon in WSL, on the default port. And it starts, without any warning or error. But: Windows 10 has actually already an ssh daemon running (and on port 22)! This caught me by surprise. So when you (or VS) tries to do "ssh localhost", it connects to the ssh daemon running on Windows 10 (!!!), and not the one running in WSL.

The solution is to run the ssh daemon inside WSL on a different port, and then use that port in the VS configuration dialog. Then, everything works.

This is not trivial to find out (who would have guessed that Windows runs an ssh daemon by default, and on port 22?). And the VS error message is also very bad and tells you not much about what's going on.

I would suggest that Microsoft improves the error messages and documentation on this. Pretty sure I wouldn't be the only one to run into this.

I would also question the fact that Windows 10 runs an ssh daemon by default on the system. I am not a security expert, but this smells to me like something one shouldn't be doing.

[therealkenc]

Variation #2505 (message). The Visual C++ for Linux team has a github here.

[patrikhuber]

@therealkenc Shouldn't WSL's ssh show an error or at least a warning though if you start it on port 22, but Windows is already listening on port 22?

[therealkenc]

"WSL's ssh" is not well formed. The OpenBSD Foundation has a ssh called OpenSSH, and Canonical Ltd. (among others) distributes it. Not a WSL actionable. But to answer your question; no. OpenSSH by default fiat does a setsockopt(...SO_REUSEADDR...), so it will listen even if the port is occupied. This is the case on both WSL and Real Linux (natch). As an experiment, on Real Linux™ you can try for example:

$ nc -l 2222

... and then in another term:

$ /usr/sbin/sshd -D -p 2222

OpenSSH sshd will fire up without warning. And behave badly.

[patrikhuber]

so it will listen even if the port is occupied

Wow!
Learned something the hard way then. That's quite surprising.
Thank you very much for the explanation :-)