Vscode-remote-release: Windows Server Support

[r3volution11]

After spending a few hours getting OpenSSH to work with pubkey authentication (Microsoft's guide is 💩), I was excited to finally give this a shot. Then I get the error that only Linux or WSL servers are supported.

So it'd be great for that support to be added.

But in the meantime please try pointing out, in a bigger and much easier to find notification, that Windows isn't supported yet in this manner.

Thanks!

[roblourens]

That's planned, and mentioned near the top of the docs: https://code.visualstudio.com/docs/remote/ssh#_connect-to-a-remote-host but can you explain what you mean about our auth documentation not being helpful?

[r3volution11]

The Linux Server only support isn't mentioned in the announcement blog entry at all (https://code.visualstudio.com/blogs/2019/05/02/remote-development). On the extension's page (https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-ssh), it is only a small note which may escape others just like it did me. I'm just suggesting maybe add a bit more prominence to it. It's especially befuddling considering Code is a Microsoft product.

As for auth documentation, I was actually referring to MS's documentation on how to set up OpenSSH (https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse) with public key auth instead of a password. Luckily many others had the same problem and got together to figure it out (https://github.com/PowerShell/Win32-OpenSSH/issues/1306). Adidtionally I had created authorized_keys in Code. OpenSSH expects Windows line endings and Code was set up for Linux. Fun! 😆

[roblourens]

Thanks for explaining. Sorry you lost some time. It's on the way!

[Chuxel]

@r3volution11 @roblourens Yes, there's also a C:\ProgramData\ssh\administrator_authorized_keys you need to add your key to if your an administrator. We'll add a similar summary to the ones for other operating systems to docs once we support it.

[r3volution11]

@Chuxel Well funny enough, apparently I don't need that. I went back and forth during my troubleshooting to see if that was (part of) the problem. I have it currently commented out and it's working just fine.

Setting up a SSH server on Windows is a lot trickier than it should be. 😅

[hbsmith]

@roblourens To piggy back on @r3volution11's comment, there is no mention of the SSH host Linux restriction on the remote development extension page (https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.vscode-remote-extensionpack), and it is only mentioned in passing in the third paragraph of the remote - ssh extension page (https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-ssh). The only page it is highlighted on at all is in the docs (https://code.visualstudio.com/docs/remote/ssh#_getting-started) but even then it's not mentioned until after the introduction and installation instructions.

It's great to hear you all are working on Windows SSH hosting support (and hopefully macOS too!), but in the meantime, can you update the extension description and docs to call out the Linux restriction much more clearly and early than you have currently? It would save people like me the time of installing and configuring Code - Insiders and the extensions only to realize after the fact that they can't set up the SSH host they were expecting to be able to :).

[cliffordfajardo]

Dropping this error message as a comment here for other's (I had trouble finding this thread) ...in case someone else is trying to SSH into a Windows machine with VS Code Remote SSH (_I can SSH fine via the my mac terminal into my Windows 10 machine fine without the extensions_)

Ran into the same issue the OP r3volution11 said with these error messages from Remote -SSH debug logs

> 'bash' is not recognized as an internal or external command,
> operable program or batch file.
"uname" terminal command done
windows10thinkpad: unreachable or not Linux x86_64. (operable program or batch file.)

[zwn]

Is there any time frame for this feature? I've found only #916 but nothing more forward looking.

[LeonardKoenig]

I have the following work-around for Visual C++, but should work analogously for other setups:

1. Setup WSL in the Windows host, install ssh and -- if necessary -- create firewall rules in the Windows host to allow access to the respective port (TCP & UDP for VS Code remote).

2. Create a file called eg. cmdrc.bat in your Windows Users' Directory containing a call to the VS Command Line Tools batchfile and a small embedded bash script to loop over the %PATH% variable's entries and run wslpath on each to convert them to UNIX-Style ones and do the translation from UCS / non-ISO extended ANSI encoding to UTF-8 for you. Basically this script gives you a list of %PATH% entries as would be seen by Linux.

   Adjust the path to the command line tools accordingly.

   @echo off
   call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Auxiliary\Build\vcvars64.bat" >nul
   wsl.exe IFS=';'; path="%PATH%"; for x in $path; do if [ -n "$x" ]; then wslpath $x; fi; done
   

3. Append a script to your .bashrc to call the batch file on login and append each line to your $PATH. We need to first cd into the Users directory, otherwise cmd.exe will complain and path handling would be more ugly. Adjust this path, too.
   bash pushd '/mnt/c/Users/Leonard König/' >/dev/null VCTOOLS=$(/init cmdrc.bat) IFS=$'\n'; for x in $VCTOOLS; do export PATH="$PATH:$x"; done; popd >/dev/null
4. Now install VS Code on your host system, the C++ Extension and Remote development extension, connect and it will bootstrap the vscode remote server. You can now basically follow along the guide for setting up MSVC, although you have to adjust a few things:
   
   
   
   1. For the c_cpp_properties:
      
      
      
      
      
      1. Add a new Win32 configuration
      
      
      
      2. Specify the full path to cl.exe as seen from Linux
      
      
      
      3. Change intelli-sense mode to msvc
      
      
      
      4. Add the include directories, eg.
         
         
         /mnt/c/Program Files (x86)/Windows Kits/10/Include/10.0.17763.0/ucrt/ /mnt/c/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/VC/Tools/MSVC/14.21.27702/include/
      
      
      
      5. Add the defines and desired Windows SDK
      
      
      
   
   
   2. For the tasks:
      
      
      
      
      
      1. Create msvc build task, with type shell. I also had to do change the shell to bash, as I didn't have zsh.
         
         
         json { "tasks": [ { "type": "shell", "options": { "shell": { "executable": "/bin/bash", "args": ["-c"], } }, " ... " } ] }
      
      
      
      2. The command and args are the same as in the normal guide, as is the other stuff.
      
      
      
      3. Be sure that your project directory is not in the Linux but on your regular Windows system, otherwise launching cl.exe won't work properly, as it cannot find your source(s).
      
      
      
   
   

---

Bottom line: This is an insane and utterly horrible hack that I've probably wasted too much time on for likely never using it (although I would appreciate a proper solution as I do not want to use a crappy [sorry] Windows for developing). But maybe someone wants to expand on it or use really use it.

[foobar8675]

for remote work, is it possible to install vscode on the ubuntu plugin on a windows 10 machine and do remote work that way?

[bersbersbers]

for remote work, is it possible to install vscode on the ubuntu plugin on a windows 10 machine and do remote work that way?

You have just described the Visual Studio Code Remote - WSL extension:
https://code.visualstudio.com/docs/remote/wsl
(hmm, maybe I have misread the "remote" part)

[Mossop]

for remote work, is it possible to install vscode on the ubuntu plugin on a windows 10 machine and do remote work that way?

This is what I do right now. There are issues though, particularly the file-watcher that vscode uses in WSL locks files (https://github.com/Microsoft/WSL/issues/1956). Hopefully this will be fixed in WSL2 though.

[MrStLouis]

stretch goal for this sprint, bummer. greatly anticipating this release as this will solve massive development headache for my team and our window server only application

[roblourens]

We now have very experimental support for connecting to windows remotes.

• Use VS Code Insiders: https://code.visualstudio.com/insiders/
• Install the SSH Nightly extension (uninstall the stable version)
• Set "remote.SSH.remoteIsWindows": true
• Connect to a windows remote over SSH

Make sure you revert that setting before trying to connect to a linux remote. In the future the setting will not be necessary. Not every feature of the ssh extension is supported yet, but I would appreciate anyone who wants to try it and report issues or feedback.

---

Known issues:

• Will not work with powershell configured as the default ssh shell
• User needs admin rights
• Remote extension host is unstable (randomly disconnecting)

[bersbersbers]

@roblourens having installed [email protected], remote.SSH.remoteIsWindows is detected as an unknown configuration setting. Is that what you mean by "not yet a documented setting"?

I guess it is, because VS Code tries to do some Powershell magic. Unfortunately:

[10:17:42.683] Showing password prompt
[10:17:47.196] Got password response
[10:17:47.197] "install" wrote data to terminal: "****"
[10:17:47.202] >

[10:17:47.365] > ''powershell' is not recognized as an internal or external command,
operable program or batch file.

[10:17:47.659] "install" terminal command done
[10:17:47.660] Install terminal quit with output: operable program or batch file.
[10:17:47.660] Received install output: operable program or batch file.
[10:17:47.660] Failed to parse remote port from server output
[10:17:47.661] Resolver error:
[10:17:47.662] TELEMETRY: {"eventName":"resolver","properties":{"outcome":"failure","reason":"UnparsableOutput","askedPw":"1","askedPassphrase":"0","asked2fa":"0","askedHostKey":"0","gotUnrecognizedPrompt":"0","remoteInConfigFile":"1"},"measures":{"resolveAttempts":1,"retries":1}}
[10:17:47.663] ------

I am using VS Code release on Windows 10 1903 to connect to a Windows 10 1809 server on a domain. I installed OpenSSH server to that server. When connecting to the server using PuTTY, the powershell command works fine, as it does locally on both systems.

I can repro the same error on my local system:
ssh remote-computer 'powershell -Command "echo 1"'

While this one is working:
ssh remote-computer "powershell -Command 'echo 1'"

Then, I went ahead and pasted the powershell -ExecutionPolicy Unrestricted ... -EncodedCommand $e" command via PuTTY, and it started the command fine when using VS Code Insiders. Combining my experience with @LeonardKoenig's below, I guess some escaping of ' and $ may still require finetuning.

I am now stuck at this:

Looking for existing server in C:\Users\bersbersbers\.vscode-server-insiders/bin/313ede61cbad8f9dc748907b3384e059ddddb79a
Downloading VS Code Server
Get-CimInstance : Access denied
At line:140 char:16
+ $winVersion = (Get-CimInstance Win32_OperatingSystem).Version
+                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : PermissionDenied: (root\cimv2:Win32_OperatingSystem:String) [Get-CimInstance], CimException
    + FullyQualifiedErrorId : HRESULT 0x80041003,Microsoft.Management.Infrastructure.CimCmdlets.GetCimInstanceCommand

cf8a9264120c: start
sshAuthSock====
agentPort==62758==
osReleaseId==windows==
osVersion====
arch==x64==
cf8a9264120c: end
Get-CimInstance : Access denied
At line:158 char:15
+ $parentPID = (Get-CimInstance win32_process | ? processid -eq $curren ...
+               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : PermissionDenied: (root\cimv2:win32_process:String) [Get-CimInstance], CimException
    + FullyQualifiedErrorId : HRESULT 0x80041003,Microsoft.Management.Infrastructure.CimCmdlets.GetCimInstanceCommand

Could not find an sshd parent of this process

Do I need need to login as a user with admin rights on the host? It seems so, as logging in as admin gets me a bit further. However, it's weird that a server is said to be running already.

Looking for existing server in C:\Users\admin\.vscode-server-insiders/bin/313ede61cbad8f9dc748907b3384e059ddddb79a
Downloading VS Code Server
vscode-server with 313ede61cbad8f9dc748907b3384e059ddddb79a is already running.
Server did not start successfully. Full server log >>>
cat : Cannot find path 'C:\Users\admin\.vscode-server-insiders\.313ede61cbad8
f9dc748907b3384e059ddddb79a.log' because it does not exist.
At line:127 char:1
+ cat $logfile
+ ~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (C:\Users\admin...059ddddb79a.l
   og:String) [Get-Content], ItemNotFoundException
    + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetCo
   ntentCommand

<<< End of server log

But after a restart, that seems to have been resolved, too:

vscode-server already installed. Skipping download...
2397439ad958: start
sshAuthSock====
agentPort==50004==
osReleaseId==windows==
osVersion==10.0.17763==
arch==x64==
2397439ad958: end
Install script is 4144, watching sshd parent 14328

So my first summary is:

• fix single and double quotation marks
• obtain windows version in a way that does not require admin rights
• make sure VS Code Server instances are stopped when setup errors occur, so that subsequent server setups can succeed.

[LeonardKoenig]

@roblourens Thanks for your work!

I get this output (using the "old" default powershell):

[10:17:27.345] > =[Convert]::ToBase64String : The term '=[Convert]::ToBase64String' is not recognized as the name of a cmdlet, 
> function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the 
> path is correct and try again.
> At line:1 char:1
> + =[Convert]::ToBase64String  ...
> + ~~~~~~~~~~~~~~~~~~~~~~~~~~
>     + CategoryInfo          : ObjectNotFound: (=[Convert]::ToBase64String:String) [], CommandNotFoundException
>     + FullyQualifiedErrorId : CommandNotFoundException
>  

Maybe it's my setup though:

Linux-Host with a Windows-VM and a Linux-Client that has a port open on localhost that I connect through which is just an SSH tunnel to the Windows-VM's ssh port. But it's all transparent and should actually not affect the problem at hand.

[r3volution11]

I've been testing out the new Nightly Remote SSH extension with Insider on Catalina connecting to a Windows 10 VM server. For the most part, it works well, however, it loses connection and requires the window to be reloaded often. Every 5-10 minutes or so. Also, it doesn't appear to work with git.

[roblourens]

The errors about the script syntax should be fixed now, but if you have powershell configured as your default ssh shell, that will still not work unfortunately. Also it looks like your user will need admin rights, I'm still looking into that.

[r3volution11]

After further testing git actually works fine. I just needed to add the root folder of the repo to the window.

But the connection issues still happen. It's much more frequent than I said before. More like 2-5 minutes.

[roblourens]

Other people have mentioned that too, it looks like the remote extension host is crashing, I will have to investigate some more.

[r3volution11]

Just tested the time. Pretty much exactly 5 minutes.

[bersbersbers]

The errors about the script syntax should be fixed now, but if you have powershell configured as your default ssh shell, that will still not work unfortunately. Also it looks like your user will need admin rights, I'm still looking into that.

2019.10.3780 is connecting fine now (SSH seems to be using cmd.exe, not PowerShell) with admin rights. Now I am seeing similar disconnects to what others have described.

[roblourens]

@bersbers interesting, I didn't change anything that would have affected the errors you saw. But I haven't actually tested a non-admin user myself yet. However I think I have fixed the random disconnect issue.

[bersbersbers]

@roblourens looks like it, yes - connection remained pretty stable for a while. I'll wait to be able to connect as a non-admin before continuing any further tests if that's OK - there's no point in installing interpreters and stuff in the admin profile on the host if that's not what I'll be using later. (You sound as if being able to work as a non-admin on the host is a reasonable assumption.) Thanks for your work so far!

[Mossop]

Here the vscode server doesn't seem to start correctly but there are no obvious errors in the log. Looks like it exits with exit code 32?

Edit: Figured this out. I ran the server directly from the machine and unblocked node from the firewall. This are working better after that.

[10:34:59.731] Install and start server if needed
[10:35:01.969] > Looking for existing server in C:\Users\Dave\.vscode-server-insiders/bin/f5d3ffa6a0d655c87e1eb0e1e90773df58f7ff25
> vscode-server already installed. Skipping download...
[10:35:01.969] Got some output, clearing connection timeout
[10:35:01.986] > Starting server...
[10:35:06.371] > Server did not start successfully. Full server log >>>
> 
> 
[10:35:06.374] > *
> * Visual Studio Code Server
> *
> * Reminder: You may only use this software with Visual Studio family products,
> * as described in the license https://aka.ms/vscode-remote/license
> *
> 
> 
> IP Address: 192.168.34.209
> IP Address: 10.0.75.1
> IP Address: 10.248.24.44
> IP Address: 192.168.159.1
> IP Address: 192.168.184.1
[10:35:06.613] > Extension host agent listening on 61384
> 
> 
> [10:35:05] Extension host agent started.
> <<< End of server log
> b7975da049ea##32##
[10:35:06.879] "install" terminal command done
[10:35:06.879] Install terminal quit with output: b7975da049ea##32##
[10:35:06.879] Received install output: b7975da049ea##32##
[10:35:06.880] Resolver error: The VS Code Server failed to start
[10:35:06.883] TELEMETRY: {"eventName":"resolver","properties":{"outcome":"failure","reason":"ExitCode","askedPw":"0","askedPassphrase":"0","asked2fa":"0","askedHostKey":"0","gotUnrecognizedPrompt":"0","remoteInConfigFile":"1"},"measures":{"resolveAttempts":1,"exitCode":32,"retries":1}}
[10:35:06.884] ------

[wenzai007]

@roblourens I did as what you said,

We now have very experimental support for connecting to windows remotes.

• Use VS Code Insiders: https://code.visualstudio.com/insiders/
• Install the SSH Nightly extension (uninstall the stable version)
• Set "remote.SSH.remoteIsWindows": true
• Connect to a windows remote over SSH

Make sure you revert that setting before trying to connect to a linux remote. In the future the setting will not be necessary. Not every feature of the ssh extension is supported yet, but I would appreciate anyone who wants to try it and report issues or feedback.

Known issues:

• Will not work with powershell configured as the default ssh shell
• User needs admin rights
• Remote extension host is unstable (randomly disconnecting)

but when I tried to connect to the windows host(os is windows server 2016), I got this error of

[00:48:42.922] Cleaning up other-window auth server
[00:48:45.092] > Looking for existing server in C:\Users\myname.vscode-server-insiders/bin/37d34176a6ecf1d09b16a0cad11bb619f3b1e48f

 Downloading VS Code Server
[00:48:45.237] > Failed to download & extract vscode-server. - The underlying connection was closed: An unexpected error occurred on a send.
 c0a9c6674581##25##
[00:48:45.299] > local-server> ssh child died, shutting down
[00:48:45.327] Local server exit: 0
[00:48:45.327] Install terminal quit with output: Looking for existing server in C:\Users\myname.vscode-server-insiders/bin/37d34176a6ecf1d09b16a0cad11bb619f3b1e48f
Downloading VS Code Server
Failed to download & extract vscode-server. - The underlying connection was closed: An unexpected error occurred on a send.
c0a9c6674581##25##

[00:48:45.327] Received install output: Looking for existing server in C:\Users\myname.vscode-server-insiders/bin/37d34176a6ecf1d09b16a0cad11bb619f3b1e48f
Downloading VS Code Server
Failed to download & extract vscode-server. - The underlying connection was closed: An unexpected error occurred on a send.
c0a9c6674581##25##

[00:48:45.328] Server download failed
[00:48:45.329] Resolver error: Downloading VS Code Server failed. Please try again later.
[00:48:45.334] ------

How could I fix this? It cost me a night to go though all kinds of errors but still cannot connect successfully, wondering is it already supported or not in VScode for the windows to windows ssh connection for now?

[roblourens]

"An unexpected error occurred on a send" we got that error while downloading the server, I haven't seen that before, sorry. We apparently got that while downloading the vscode server component. There is a feature to download on the client when download on the host fails, but I haven't implemented that for Windows yet.

[wenzai007]

"An unexpected error occurred on a send" we got that error while downloading the server, I haven't seen that before, sorry. We apparently got that while downloading the vscode server component. There is a feature to download on the client when download on the host fails, but I haven't implemented that for Windows yet.

@roblourens, thanks for reply, if regardless for client to download, so the vscode server is necessary for the host right? But seems vscode server only have linux version, but no WIndows version, it that right? So how could it be successful for a Windows Host to be connected from a Windows Client? Or is it that I must use the way of WSL to do that? (https://code.visualstudio.com/docs/remote/wsl)

[roblourens]

No, there is a Windows version of the server. It's just failing to download here and I don't know why.

[wenzai007]

No, there is a Windows version of the server. It's just failing to download here and I don't know why.

Thanks @roblourens, my host is Windows Server 2016 (OS build 14393.3274). Is there a vscode server for this? And can I download it manually?If yes, could you share the link of it? As I did not find any matching this version by searching.

[r3volution11]

Interesting git issue: When I'm connected to my Windows server with folder that has a git repo it seems to lock the index. When I attempt to stage changes outside of Code it errors out with an index issue. Closing the connection fixes the issue. Just FYI.

[superphonic]

@roblourens I am also getting Failed to download & extract vscode-server. - The underlying connection was closed: An unexpected error occurred on a send. When using the windows version. Is there somewhere we can download the windows vscode server to install/run manually on the host?

[roblourens]

@r3volution11 please file an issue and include the log from the Git output channel, thanks

@superphonic no, I will have to come up with an environment where I can repro this...

[alan-hu]

I just installed VS Code Insider v1.41.0 on Windows 10. And my remote server is a Windows 2016 server with OpenSSH configured and running.

The error messages I got are:

[14:53:18.312] [email protected]
[14:53:18.312] win32 x64
[14:53:18.318] SSH Resolver called for "ssh-remote+My-Remote-Win2016-server", attempt 1
[14:53:18.319] SSH Resolver called for host: My-Remote-Win2016-server
[14:53:18.319] Setting up SSH remote "My-Remote-Win2016-server"
[14:53:18.398] Using commit id "0d728c31ebdf03869d2687d9be0b017667c9ff37" and quality "insider" for server
[14:53:18.402] Testing ssh with ssh -V
[14:53:18.581] ssh exited with code: 0
[14:53:18.581] Got stderr from ssh: OpenSSH_for_Windows_8.0p1, LibreSSL 2.6.5
[14:53:18.582] Remote command length: 5868/8192 characters
[14:53:18.592] Install and start server if needed
[14:53:18.600] Terminal shell path: C:\Windows\System32cmd.exe
[14:53:19.627]
[14:53:19.628] Got some output, clearing connection timeout
[14:53:20.117] > My-Remote-User-Name@My-Remote-Win2016-server's password:
[14:53:28.835] >
[14:53:35.359] > Looking for existing server in C:\Users\My-Remote-User-Name.vscode-server-insiders/bin/0d728c31ebdf03869d2687d9be0b017667c9ff37
[14:53:35.424] > vscode-server already installed. Skipping download...
[14:53:35.450] > Starting server...
[14:53:39.551] > Server did not start successfully. Full server log >>>
[14:53:39.576] > <<< End of server log
c56dd488afc8##32##
[14:53:40.189] "install" terminal command done
[14:53:40.190] Install terminal quit with output: c56dd488afc8##32##
[14:53:40.190] Received install output: c56dd488afc8##32##
[14:53:40.191] Resolver error: The VS Code Server failed to start
[14:53:40.200] ------

The log file on my remote server at location "C:\Users\0axhu.vscode-server-insiders.0d728c31ebdf03869d2687d9be0b017667c9ff37.log" contains nothing. Just an empty file.

[wibjorn]

Thanks for making this happen! Managed to try today, with the following result. VSCode popped up an generic massage saying Process Exited with Code 1, but in the end despite this it seemed to work. It was a Windows 10 image. Very exiting!

****@****'s password: 
Looking for existing server in C:\omitted
insiders/bin/86405ea23e3937316009fc27c9361deee66ffbf5
Downloading VS Code Server
Starting server...
8a4048f91338: start
sshAuthSock====
agentPort==50094==
osReleaseId==windows==
osVersion==10.0.17763==
arch==x64==
8a4048f91338: end
Install script is 6884, watching sshd parent 7656

Interestingly, I installed Node by using the RDP Remote Desktop Connection. However, when trying to do node ./script.js from within the remote connection, it said that it didn't recognize Node as a command. Could there be some difference in the terminal environments? I'm struggling to think why it might work in the remote viewer (in a PowerShell window), and not in the integrated terminal connected to the VM.

[ewired]

I tried using it today with a Windows 10 1809 VM and it seems like a syntax error in the one-liner given to Powershell.exe is preventing it from launching the script that starts the server. Here is the output of my Remote - SSH output section.

[13:43:09.461] Log Level: 3
[13:43:09.462] [email protected]
[13:43:09.462] linux x64
[13:43:09.464] SSH Resolver called for "ssh-remote+my-alias", attempt 1
[13:43:09.465] SSH Resolver called for host: my-alias
[13:43:09.465] Setting up SSH remote "my-alias"
[13:43:09.474] Using commit id "2d2ac8f75b539d505443ac0733b196851c0b218d" and quality "insider" for server
[13:43:09.475] Testing ssh with ssh -V
[13:43:09.483] ssh exited with code: 0
[13:43:09.483] Got stderr from ssh: OpenSSH_7.9p1 Ubuntu-10, OpenSSL 1.1.1b  26 Feb 2019
[13:43:09.483] Remote command length: 5868/8192 characters
[13:43:09.486] Running script with connection command: ssh -T -D 43417 -o ConnectTimeout=15 my-alias powershell -ExecutionPolicy Unrestricted -NoLogo -NoProfile -NonInteractive -Command "\$e=[Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes([Text.Encoding]::UTF8.GetString([Convert]::FromBase64String('CiRQcm9ncmVzc1ByZWZlcmVuY2UgPSAnU2lsZW50bHlDb250aW51ZScKJGNvbW1pdElkID0gJzJkMmFjOGY3NWI1MzlkNTA1NDQzYWMwNzMzYjE5Njg1MWMwYjIxOGQnCgokdnNjb2RlQXJjaCA9IGlmICgoJGVudjpQUk9DRVNTT1JfQVJDSElURUNUVVJFIC1lcSAnQU1ENjQnKSAtb3IgKCRlbnY6UFJPQ0VTU09SX0FSQ0hJVEVDVFVSRSAtZXEgJ0lBNjQnKSkgeyAneDY0JyB9IGVsc2UgeyAnaWEzMicgfQoKJHNlcnZlclJvb3QgPSAoSm9pbi1QYXRoIChSZXNvbHZlLVBhdGggfikgJy52c2NvZGUtc2VydmVyLWluc2lkZXJzJykKJGVudjpWU0NPREVfQUdFTlRfRk9MREVSPSRzZXJ2ZXJSb290CiRsb2dmaWxlID0gIiRzZXJ2ZXJSb290Ly4kY29tbWl0SWQubG9nIgokc2VydmVyRGlyID0gIiRzZXJ2ZXJSb290L2Jpbi8kY29tbWl0SWQiCiRxdWFsaXR5ID0gJ2luc2lkZXInCiR0ZWxlbWV0cnkgPSAiIgokZXh0ZW5zaW9ucyA9ICIiCiR3ZWJQYXJ0ID0gIiIKJHNlcnZlck5hbWUgPSAic2VydmVyLXdpbjMyLSR2c2NvZGVBcmNoIiArICR3ZWJQYXJ0CgppZiAoJHF1YWxpdHkgLWVxICdzdGFibGUnKSB7CmVjaG8gIldpbmRvd3MgaG9zdHMgYXJlIG9ubHkgc3VwcG9ydGVkIHdoZW4gcnVubmluZyBWUyBDb2RlIEluc2lkZXJzIgplY2hvICJlZjRhZmYwZWQ5ODUjIzMzIyMiCmV4aXQgMAp9CgpmdW5jdGlvbiBEb3dubG9hZFNlcnZlciB7CmVjaG8gIkRvd25sb2FkaW5nIFZTIENvZGUgU2VydmVyIgokc3BsYXQgPSBAewpVcmk9Imh0dHBzOi8vdXBkYXRlLmNvZGUudmlzdWFsc3R1ZGlvLmNvbS9jb21taXQ6JGNvbW1pdElkLyRzZXJ2ZXJOYW1lLyRxdWFsaXR5IgpUaW1lb3V0U2VjPTIwCk91dEZpbGU9IiRzZXJ2ZXJOYW1lLnppcCIKVXNlQmFzaWNQYXJzaW5nPSRUcnVlCn0KCkludm9rZS1SZXN0TWV0aG9kIEBzcGxhdAoKRXhwYW5kLUFyY2hpdmUgIiRzZXJ2ZXJOYW1lLnppcCIgLURlc3RpbmF0aW9uUGF0aCAiJGVudjpURU1QL3ZzY29kZS1zZXJ2ZXItJGNvbW1pdElkIgpNb3ZlLUl0ZW0gIiRlbnY6VEVNUC92c2NvZGUtc2VydmVyLSRjb21taXRJZC92c2NvZGUtJHNlcnZlck5hbWUvKiIgLURlc3RpbmF0aW9uIC4KfQoKaWYoIShUZXN0LVBhdGggJHNlcnZlckRpcikpIHsKdHJ5IHsKJG51bGwgPSBOZXctSXRlbSAtSXRlbVR5cGUgRGlyZWN0b3J5ICRzZXJ2ZXJEaXIgLUZvcmNlIC1FcnJvckFjdGlvbiBTaWxlbnRseUNvbnRpbnVlCn0gY2F0Y2ggewplY2hvICJDb3VsZCBub3QgY3JlYXRlIHZzY29kZS1zZXJ2ZXIgZGlyZWN0b3J5LiAtICQoJF8uVG9TdHJpbmcoKSkiCnJldHVybgp9CgppZighKFRlc3QtUGF0aCAkc2VydmVyRGlyKSkgewplY2hvICJDb3VsZCBub3QgY3JlYXRlIHZzY29kZS1zZXJ2ZXIgZGlyZWN0b3J5LiIKcmV0dXJuCn0KfQoKY2QgJHNlcnZlckRpcgoKJGxvY2tGaWxlUGF0aCA9IChKb2luLVBhdGggIiRzZXJ2ZXJEaXIiICJ2c2NvZGUtcmVtb3RlLWxvY2suJGNvbW1pdElkIikKdHJ5IHsKJG51bGwgPSBOZXctSXRlbSAkbG9ja0ZpbGVQYXRoIC1JdGVtVHlwZSBGaWxlIC1FcnJvckFjdGlvbiBTaWxlbnRseUNvbnRpbnVlCn0gY2F0Y2ggewplY2hvICJDb3VsZCBub3QgY3JlYXRlIHZzY29kZS1zZXJ2ZXIgbG9jayBmaWxlLiAtICQoJF8uVG9TdHJpbmcoKSkiCnJldHVybgp9Cgp0cnkgewokZmlsZSA9IFtTeXN0ZW0uaW8uRmlsZV06Ok9wZW4oJGxvY2tGaWxlUGF0aCwgJ09wZW4nLCAnUmVhZCcsICdOb25lJykKfSBjYXRjaCB7CmVjaG8gIkluc3RhbGxhdGlvbiBhbHJlYWR5IGluIHByb2dyZXNzLi4uIC0gJCgkXy5Ub1N0cmluZygpKSIKZWNobyAiZWY0YWZmMGVkOTg1IyMyNCMjIgpyZXR1cm4KfQoKdHJ5IHsKZWNobyAiTG9va2luZyBmb3IgZXhpc3Rpbmcgc2VydmVyIGluICRzZXJ2ZXJEaXIiCmlmKFRlc3QtUGF0aCAiJHNlcnZlckRpci9zZXJ2ZXIuY21kIikgewplY2hvICJ2c2NvZGUtc2VydmVyIGFscmVhZHkgaW5zdGFsbGVkLiBTa2lwcGluZyBkb3dubG9hZC4uLiIKfSBlbHNlIHsKdHJ5IHsKRG93bmxvYWRTZXJ2ZXIKfSBjYXRjaCB7CmVjaG8gIkZhaWxlZCB0byBkb3dubG9hZCAmIGV4dHJhY3QgdnNjb2RlLXNlcnZlci4gLSAkKCRfLlRvU3RyaW5nKCkpIgplY2hvICJlZjRhZmYwZWQ5ODUjIzI1IyMiCnJldHVybgp9CgppZighKFRlc3QtUGF0aCAiJHNlcnZlckRpci9zZXJ2ZXIuY21kIikpIHsKZWNobyAiRmFpbGVkIHRvIGRvd25sb2FkICYgZXh0cmFjdCB2c2NvZGUtc2VydmVyLiIKZWNobyAiZWY0YWZmMGVkOTg1IyMyNSMjIgpyZXR1cm4KfQp9CgppZiAoJGV4dGVuc2lvbnMgLW5lICIiKSB7CmVjaG8gIkluc3RhbGxpbmcgZXh0ZW5zaW9ucy4uLiIKJiAiJHNlcnZlckRpci9zZXJ2ZXIuY21kIiAkdGVsZW1ldHJ5ICAjID8/Cn0KCmlmKCEoR2V0LVByb2Nlc3Mgbm9kZSAtRXJyb3JBY3Rpb24gU2lsZW50bHlDb250aW51ZSB8IFdoZXJlLU9iamVjdCBQYXRoIC1tYXRjaCAkY29tbWl0SWQpKSB7CmlmKFRlc3QtUGF0aCAkbG9nZmlsZSkgewpkZWwgJGxvZ2ZpbGUKfQokc3BsYXQgPSBAewpGaWxlUGF0aCA9ICJwb3dlcnNoZWxsLmV4ZSIKV2luZG93U3R5bGUgPSAiaGlkZGVuIgpBcmd1bWVudExpc3QgPSBAKAoiLWMiLCAiJiBgIiRzZXJ2ZXJEaXIvc2VydmVyLmNtZGAiIC0taG9zdD0xMjcuMC4wLjEgLS1lbmFibGUtcmVtb3RlLWF1dG8tc2h1dGRvd24gLS1wb3J0PTAgJHRlbGVtZXRyeSAqPiAkbG9nZmlsZSIKKQpQYXNzVGhydSA9ICRUcnVlCn0KZWNobyAiU3RhcnRpbmcgc2VydmVyLi4uIgokbGF1bmNoZWRTZXJ2ZXJQaWQgPSAoU3RhcnQtUHJvY2VzcyBAc3BsYXQpLklECn0gZWxzZSB7CmVjaG8gInZzY29kZS1zZXJ2ZXIgd2l0aCAkY29tbWl0SWQgaXMgYWxyZWFkeSBydW5uaW5nLiIKfQoKJHNwbGF0ID0gQHsKUGF0aCA9ICRsb2dmaWxlClBhdHRlcm4gPSAiRXh0ZW5zaW9uIGhvc3QgYWdlbnQgbGlzdGVuaW5nIG9uIChcZCspIgp9CgokdGltZW91dERhdGUgPSAoR2V0LURhdGUpLkFkZFNlY29uZHMoNCkKd2hpbGUgKChHZXQtRGF0ZSkgLWx0ICR0aW1lb3V0RGF0ZSkgewppZihUZXN0LVBhdGggJGxvZ2ZpbGUpIHsKJGdyb3VwcyA9IChTZWxlY3QtU3RyaW5nIEBzcGxhdCkuTWF0Y2hlcy5Hcm91cHMKaWYoJGdyb3VwcykgewokcG9ydCA9ICRncm91cHNbMV0uVmFsdWUKYnJlYWsKfQp9ClN0YXJ0LVNsZWVwIC1NaWxsaXNlY29uZHMgNTAwCn0KCmlmICghJHBvcnQpIHsKZWNobyAiU2VydmVyIGRpZCBub3Qgc3RhcnQgc3VjY2Vzc2Z1bGx5LiBGdWxsIHNlcnZlciBsb2cgPj4+IgpjYXQgJGxvZ2ZpbGUKZWNobyAiPDw8IEVuZCBvZiBzZXJ2ZXIgbG9nIgplY2hvICJlZjRhZmYwZWQ5ODUjIzMyIyMiCnJldHVybgp9Cn0gY2F0Y2ggewplY2hvICJ2c2NvZGUtc2VydmVyIGZhaWxlZCB0byBzdGFydC4gLSAkKCRfLlRvU3RyaW5nKCkpIgp9IGZpbmFsbHkgewokZmlsZS5DbG9zZSgpCn0KCgp0cnkgewokd2luVmVyc2lvbiA9IChHZXQtQ2ltSW5zdGFuY2UgV2luMzJfT3BlcmF0aW5nU3lzdGVtKS5WZXJzaW9uCn0gY2F0Y2ggewplY2hvICJGYWlsZWQgdG8gZmluZCBXaW5kb3dzIHZlcnNpb24gLSAkKCRfLlRvU3RyaW5nKCkpIgokd2luVmVyc2lvbiA9ICJ1bmtub3duIgp9CgplY2hvICJlZjRhZmYwZWQ5ODU6IHN0YXJ0IgplY2hvICJzc2hBdXRoU29jaz09JGVudjpTU0hfQVVUSF9TT0NLPT0iCmVjaG8gImFnZW50UG9ydD09JHBvcnQ9PSIKZWNobyAib3NSZWxlYXNlSWQ9PXdpbmRvd3M9PSIKZWNobyAib3NWZXJzaW9uPT0kd2luVmVyc2lvbj09IgplY2hvICJhcmNoPT0kdnNjb2RlQXJjaD09IgplY2hvICJlZjRhZmYwZWQ5ODU6IGVuZCIKCgoKJGN1cnJlbnRQSUQgPSAkUElECndoaWxlICgkVHJ1ZSkgewokcGFyZW50UElEID0gKEdldC1DaW1JbnN0YW5jZSB3aW4zMl9wcm9jZXNzIHwgPyBwcm9jZXNzaWQgLWVxICRjdXJyZW50UElEKS5wYXJlbnRwcm9jZXNzaWQKaWYgKCEkcGFyZW50UElEKSB7CmVjaG8gIkNvdWxkIG5vdCBmaW5kIGFuIHNzaGQgcGFyZW50IG9mIHRoaXMgcHJvY2VzcyIKZXhpdCAwCn0KCmlmICgoZ3BzIC1JZCAkcGFyZW50UElEKS5OYW1lIC1lcSAnc3NoZCcpIHsKJHNzaGRQSUQgPSAkcGFyZW50UElECmJyZWFrCn0KCiRjdXJyZW50UElEID0gJHBhcmVudFBJRAp9CgplY2hvICJJbnN0YWxsIHNjcmlwdCBpcyAkcGlkLCB3YXRjaGluZyBzc2hkIHBhcmVudCAkc3NoZFBJRCIKd2hpbGUgKCRUcnVlKSB7CmlmICgkbGF1bmNoZWRTZXJ2ZXJQaWQpIHsKaWYgKCEoZ3BzIC1JZCAkbGF1bmNoZWRTZXJ2ZXJQaWQpKSB7CmVjaG8gIlRoZSBsYXVuY2hlZCBzZXJ2ZXIgZGllZCwgZXhpdGluZyIKZXhpdCAwCn0KfSBlbHNlIHsKaWYgKCEoZ3BzIC1JZCAkc3NoZFBJRCkpIHsKZWNobyAiVGhlIHNzaGQgcGFyZW50IGRpZWQsIGV4aXRpbmciCmV4aXQgMAp9Cn0KClN0YXJ0LVNsZWVwIDMwCn0K')))); powershell -ExecutionPolicy Unrestricted -NoLogo -NoProfile -NonInteractive -EncodedCommand \$e"
[13:43:09.486] Install and start server if needed
[13:43:09.805] > [email protected]'s password: 
[13:43:09.805] Got some output, clearing connection timeout
[13:43:09.807] Showing password prompt
[13:43:19.090] Got password response
[13:43:19.091] "install" wrote data to terminal: "**************"
[13:43:19.109] > 
[13:43:19.610] > =[Convert]::ToBase64String : The term '=[Convert]::ToBase64String' is not recognized as the name of a cmdlet, 
> function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the 
> path is correct and try again.
> At line:1 char:1
> + =[Convert]::ToBase64String 10 0 36 0 80 0 114 0 111 0 103 0 114 0 101 ...
> + ~~~~~~~~~~~~~~~~~~~~~~~~~~
>     + CategoryInfo          : ObjectNotFound: (=[Convert]::ToBase64String:String) [], CommandNotFoundException
>     + FullyQualifiedErrorId : CommandNotFoundException
>  
[13:43:19.694] > Cannot process the command because of a missing parameter. A command must follow -Command.
> 
> PowerShell[.exe] [-PSConsoleFile <file> | -Version <version>]
>     [-NoLogo] [-NoExit] [-Sta] [-Mta] [-NoProfile] [-NonInteractive]
>     [-InputFormat {Text | XML}] [-OutputFormat {Text | XML}]
>     [-WindowStyle <style>] [-EncodedCommand <Base64EncodedCommand>]
>     [-ConfigurationName <string>]
>     [-File <filePath> <args>] [-ExecutionPolicy <ExecutionPolicy>]
>     [-Command { - | <script-block> [-args <arg-array>]
>                   | <string> [<CommandParameters>] } ]
> 
> PowerShell[.exe] -Help | -? | /?
> 
> ...
[13:43:19.950] "install" terminal command done
[13:43:19.950] Install terminal quit with output:     powershell.exe -encodedCommand $encodedCommand
[13:43:19.950] Received install output:     powershell.exe -encodedCommand $encodedCommand
[13:43:19.951] Stopped parsing output early. Remaining text: powershell.exe -encodedCommand $encodedCommand
[13:43:19.951] Failed to parse remote port from server output
[13:43:19.951] Resolver error: 
[13:43:19.954] ------

[roblourens]

Assuming it's this, I think it won't work if the default ssh shell is powershell: https://github.com/microsoft/vscode-remote-release/issues/1871

[ewired]

Thanks @roblourens. I configured my Windows 10 OpenSSH server to use cmd.exe instead, and it gets to download and run the remote server. It seems I've made some progress, but there's a different error from the actual server itself now.

[16:28:42.364] Log Level: 3
[16:28:42.365] [email protected]
[16:28:42.365] linux x64
[16:28:42.367] SSH Resolver called for "ssh-remote+my-alias", attempt 1
[16:28:42.367] SSH Resolver called for host: my-alias
[16:28:42.368] Setting up SSH remote "my-alias"
[16:28:42.385] Using commit id "241d4048aabc31db0baed66bb3d58cf3210d981d" and quality "insider" for server
[16:28:42.387] Testing ssh with ssh -V
[16:28:42.400] ssh exited with code: 0
[16:28:42.401] Got stderr from ssh: OpenSSH_7.9p1 Ubuntu-10, OpenSSL 1.1.1b  26 Feb 2019
[16:28:42.402] Remote command length: 5868/8192 characters
[16:28:42.406] Running script with connection command: ssh -T -D 38337 -o ConnectTimeout=15 my-alias powershell -ExecutionPolicy Unrestricted -NoLogo -NoProfile -NonInteractive -Command "\$e=[Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes([Text.Encoding]::UTF8.GetString([Convert]::FromBase64String('CiRQcm9ncmVzc1ByZWZlcmVuY2UgPSAnU2lsZW50bHlDb250aW51ZScKJGNvbW1pdElkID0gJzI0MWQ0MDQ4YWFiYzMxZGIwYmFlZDY2YmIzZDU4Y2YzMjEwZDk4MWQnCgokdnNjb2RlQXJjaCA9IGlmICgoJGVudjpQUk9DRVNTT1JfQVJDSElURUNUVVJFIC1lcSAnQU1ENjQnKSAtb3IgKCRlbnY6UFJPQ0VTU09SX0FSQ0hJVEVDVFVSRSAtZXEgJ0lBNjQnKSkgeyAneDY0JyB9IGVsc2UgeyAnaWEzMicgfQoKJHNlcnZlclJvb3QgPSAoSm9pbi1QYXRoIChSZXNvbHZlLVBhdGggfikgJy52c2NvZGUtc2VydmVyLWluc2lkZXJzJykKJGVudjpWU0NPREVfQUdFTlRfRk9MREVSPSRzZXJ2ZXJSb290CiRsb2dmaWxlID0gIiRzZXJ2ZXJSb290Ly4kY29tbWl0SWQubG9nIgokc2VydmVyRGlyID0gIiRzZXJ2ZXJSb290L2Jpbi8kY29tbWl0SWQiCiRxdWFsaXR5ID0gJ2luc2lkZXInCiR0ZWxlbWV0cnkgPSAiIgokZXh0ZW5zaW9ucyA9ICIiCiR3ZWJQYXJ0ID0gIiIKJHNlcnZlck5hbWUgPSAic2VydmVyLXdpbjMyLSR2c2NvZGVBcmNoIiArICR3ZWJQYXJ0CgppZiAoJHF1YWxpdHkgLWVxICdzdGFibGUnKSB7CmVjaG8gIldpbmRvd3MgaG9zdHMgYXJlIG9ubHkgc3VwcG9ydGVkIHdoZW4gcnVubmluZyBWUyBDb2RlIEluc2lkZXJzIgplY2hvICJhZDMyZDc1MzVhZDkjIzMzIyMiCmV4aXQgMAp9CgpmdW5jdGlvbiBEb3dubG9hZFNlcnZlciB7CmVjaG8gIkRvd25sb2FkaW5nIFZTIENvZGUgU2VydmVyIgokc3BsYXQgPSBAewpVcmk9Imh0dHBzOi8vdXBkYXRlLmNvZGUudmlzdWFsc3R1ZGlvLmNvbS9jb21taXQ6JGNvbW1pdElkLyRzZXJ2ZXJOYW1lLyRxdWFsaXR5IgpUaW1lb3V0U2VjPTIwCk91dEZpbGU9IiRzZXJ2ZXJOYW1lLnppcCIKVXNlQmFzaWNQYXJzaW5nPSRUcnVlCn0KCkludm9rZS1SZXN0TWV0aG9kIEBzcGxhdAoKRXhwYW5kLUFyY2hpdmUgIiRzZXJ2ZXJOYW1lLnppcCIgLURlc3RpbmF0aW9uUGF0aCAiJGVudjpURU1QL3ZzY29kZS1zZXJ2ZXItJGNvbW1pdElkIgpNb3ZlLUl0ZW0gIiRlbnY6VEVNUC92c2NvZGUtc2VydmVyLSRjb21taXRJZC92c2NvZGUtJHNlcnZlck5hbWUvKiIgLURlc3RpbmF0aW9uIC4KfQoKaWYoIShUZXN0LVBhdGggJHNlcnZlckRpcikpIHsKdHJ5IHsKJG51bGwgPSBOZXctSXRlbSAtSXRlbVR5cGUgRGlyZWN0b3J5ICRzZXJ2ZXJEaXIgLUZvcmNlIC1FcnJvckFjdGlvbiBTaWxlbnRseUNvbnRpbnVlCn0gY2F0Y2ggewplY2hvICJDb3VsZCBub3QgY3JlYXRlIHZzY29kZS1zZXJ2ZXIgZGlyZWN0b3J5LiAtICQoJF8uVG9TdHJpbmcoKSkiCnJldHVybgp9CgppZighKFRlc3QtUGF0aCAkc2VydmVyRGlyKSkgewplY2hvICJDb3VsZCBub3QgY3JlYXRlIHZzY29kZS1zZXJ2ZXIgZGlyZWN0b3J5LiIKcmV0dXJuCn0KfQoKY2QgJHNlcnZlckRpcgoKJGxvY2tGaWxlUGF0aCA9IChKb2luLVBhdGggIiRzZXJ2ZXJEaXIiICJ2c2NvZGUtcmVtb3RlLWxvY2suJGNvbW1pdElkIikKdHJ5IHsKJG51bGwgPSBOZXctSXRlbSAkbG9ja0ZpbGVQYXRoIC1JdGVtVHlwZSBGaWxlIC1FcnJvckFjdGlvbiBTaWxlbnRseUNvbnRpbnVlCn0gY2F0Y2ggewplY2hvICJDb3VsZCBub3QgY3JlYXRlIHZzY29kZS1zZXJ2ZXIgbG9jayBmaWxlLiAtICQoJF8uVG9TdHJpbmcoKSkiCnJldHVybgp9Cgp0cnkgewokZmlsZSA9IFtTeXN0ZW0uaW8uRmlsZV06Ok9wZW4oJGxvY2tGaWxlUGF0aCwgJ09wZW4nLCAnUmVhZCcsICdOb25lJykKfSBjYXRjaCB7CmVjaG8gIkluc3RhbGxhdGlvbiBhbHJlYWR5IGluIHByb2dyZXNzLi4uIC0gJCgkXy5Ub1N0cmluZygpKSIKZWNobyAiYWQzMmQ3NTM1YWQ5IyMyNCMjIgpyZXR1cm4KfQoKdHJ5IHsKZWNobyAiTG9va2luZyBmb3IgZXhpc3Rpbmcgc2VydmVyIGluICRzZXJ2ZXJEaXIiCmlmKFRlc3QtUGF0aCAiJHNlcnZlckRpci9zZXJ2ZXIuY21kIikgewplY2hvICJ2c2NvZGUtc2VydmVyIGFscmVhZHkgaW5zdGFsbGVkLiBTa2lwcGluZyBkb3dubG9hZC4uLiIKfSBlbHNlIHsKdHJ5IHsKRG93bmxvYWRTZXJ2ZXIKfSBjYXRjaCB7CmVjaG8gIkZhaWxlZCB0byBkb3dubG9hZCAmIGV4dHJhY3QgdnNjb2RlLXNlcnZlci4gLSAkKCRfLlRvU3RyaW5nKCkpIgplY2hvICJhZDMyZDc1MzVhZDkjIzI1IyMiCnJldHVybgp9CgppZighKFRlc3QtUGF0aCAiJHNlcnZlckRpci9zZXJ2ZXIuY21kIikpIHsKZWNobyAiRmFpbGVkIHRvIGRvd25sb2FkICYgZXh0cmFjdCB2c2NvZGUtc2VydmVyLiIKZWNobyAiYWQzMmQ3NTM1YWQ5IyMyNSMjIgpyZXR1cm4KfQp9CgppZiAoJGV4dGVuc2lvbnMgLW5lICIiKSB7CmVjaG8gIkluc3RhbGxpbmcgZXh0ZW5zaW9ucy4uLiIKJiAiJHNlcnZlckRpci9zZXJ2ZXIuY21kIiAkdGVsZW1ldHJ5ICAjID8/Cn0KCmlmKCEoR2V0LVByb2Nlc3Mgbm9kZSAtRXJyb3JBY3Rpb24gU2lsZW50bHlDb250aW51ZSB8IFdoZXJlLU9iamVjdCBQYXRoIC1tYXRjaCAkY29tbWl0SWQpKSB7CmlmKFRlc3QtUGF0aCAkbG9nZmlsZSkgewpkZWwgJGxvZ2ZpbGUKfQokc3BsYXQgPSBAewpGaWxlUGF0aCA9ICJwb3dlcnNoZWxsLmV4ZSIKV2luZG93U3R5bGUgPSAiaGlkZGVuIgpBcmd1bWVudExpc3QgPSBAKAoiLWMiLCAiJiBgIiRzZXJ2ZXJEaXIvc2VydmVyLmNtZGAiIC0taG9zdD0xMjcuMC4wLjEgLS1lbmFibGUtcmVtb3RlLWF1dG8tc2h1dGRvd24gLS1wb3J0PTAgJHRlbGVtZXRyeSAqPiAkbG9nZmlsZSIKKQpQYXNzVGhydSA9ICRUcnVlCn0KZWNobyAiU3RhcnRpbmcgc2VydmVyLi4uIgokbGF1bmNoZWRTZXJ2ZXJQaWQgPSAoU3RhcnQtUHJvY2VzcyBAc3BsYXQpLklECn0gZWxzZSB7CmVjaG8gInZzY29kZS1zZXJ2ZXIgd2l0aCAkY29tbWl0SWQgaXMgYWxyZWFkeSBydW5uaW5nLiIKfQoKJHNwbGF0ID0gQHsKUGF0aCA9ICRsb2dmaWxlClBhdHRlcm4gPSAiRXh0ZW5zaW9uIGhvc3QgYWdlbnQgbGlzdGVuaW5nIG9uIChcZCspIgp9CgokdGltZW91dERhdGUgPSAoR2V0LURhdGUpLkFkZFNlY29uZHMoNCkKd2hpbGUgKChHZXQtRGF0ZSkgLWx0ICR0aW1lb3V0RGF0ZSkgewppZihUZXN0LVBhdGggJGxvZ2ZpbGUpIHsKJGdyb3VwcyA9IChTZWxlY3QtU3RyaW5nIEBzcGxhdCkuTWF0Y2hlcy5Hcm91cHMKaWYoJGdyb3VwcykgewokcG9ydCA9ICRncm91cHNbMV0uVmFsdWUKYnJlYWsKfQp9ClN0YXJ0LVNsZWVwIC1NaWxsaXNlY29uZHMgNTAwCn0KCmlmICghJHBvcnQpIHsKZWNobyAiU2VydmVyIGRpZCBub3Qgc3RhcnQgc3VjY2Vzc2Z1bGx5LiBGdWxsIHNlcnZlciBsb2cgPj4+IgpjYXQgJGxvZ2ZpbGUKZWNobyAiPDw8IEVuZCBvZiBzZXJ2ZXIgbG9nIgplY2hvICJhZDMyZDc1MzVhZDkjIzMyIyMiCnJldHVybgp9Cn0gY2F0Y2ggewplY2hvICJ2c2NvZGUtc2VydmVyIGZhaWxlZCB0byBzdGFydC4gLSAkKCRfLlRvU3RyaW5nKCkpIgp9IGZpbmFsbHkgewokZmlsZS5DbG9zZSgpCn0KCgp0cnkgewokd2luVmVyc2lvbiA9IChHZXQtQ2ltSW5zdGFuY2UgV2luMzJfT3BlcmF0aW5nU3lzdGVtKS5WZXJzaW9uCn0gY2F0Y2ggewplY2hvICJGYWlsZWQgdG8gZmluZCBXaW5kb3dzIHZlcnNpb24gLSAkKCRfLlRvU3RyaW5nKCkpIgokd2luVmVyc2lvbiA9ICJ1bmtub3duIgp9CgplY2hvICJhZDMyZDc1MzVhZDk6IHN0YXJ0IgplY2hvICJzc2hBdXRoU29jaz09JGVudjpTU0hfQVVUSF9TT0NLPT0iCmVjaG8gImFnZW50UG9ydD09JHBvcnQ9PSIKZWNobyAib3NSZWxlYXNlSWQ9PXdpbmRvd3M9PSIKZWNobyAib3NWZXJzaW9uPT0kd2luVmVyc2lvbj09IgplY2hvICJhcmNoPT0kdnNjb2RlQXJjaD09IgplY2hvICJhZDMyZDc1MzVhZDk6IGVuZCIKCgoKJGN1cnJlbnRQSUQgPSAkUElECndoaWxlICgkVHJ1ZSkgewokcGFyZW50UElEID0gKEdldC1DaW1JbnN0YW5jZSB3aW4zMl9wcm9jZXNzIHwgPyBwcm9jZXNzaWQgLWVxICRjdXJyZW50UElEKS5wYXJlbnRwcm9jZXNzaWQKaWYgKCEkcGFyZW50UElEKSB7CmVjaG8gIkNvdWxkIG5vdCBmaW5kIGFuIHNzaGQgcGFyZW50IG9mIHRoaXMgcHJvY2VzcyIKZXhpdCAwCn0KCmlmICgoZ3BzIC1JZCAkcGFyZW50UElEKS5OYW1lIC1lcSAnc3NoZCcpIHsKJHNzaGRQSUQgPSAkcGFyZW50UElECmJyZWFrCn0KCiRjdXJyZW50UElEID0gJHBhcmVudFBJRAp9CgplY2hvICJJbnN0YWxsIHNjcmlwdCBpcyAkcGlkLCB3YXRjaGluZyBzc2hkIHBhcmVudCAkc3NoZFBJRCIKd2hpbGUgKCRUcnVlKSB7CmlmICgkbGF1bmNoZWRTZXJ2ZXJQaWQpIHsKaWYgKCEoZ3BzIC1JZCAkbGF1bmNoZWRTZXJ2ZXJQaWQpKSB7CmVjaG8gIlRoZSBsYXVuY2hlZCBzZXJ2ZXIgZGllZCwgZXhpdGluZyIKZXhpdCAwCn0KfSBlbHNlIHsKaWYgKCEoZ3BzIC1JZCAkc3NoZFBJRCkpIHsKZWNobyAiVGhlIHNzaGQgcGFyZW50IGRpZWQsIGV4aXRpbmciCmV4aXQgMAp9Cn0KClN0YXJ0LVNsZWVwIDMwCn0K')))); powershell -ExecutionPolicy Unrestricted -NoLogo -NoProfile -NonInteractive -EncodedCommand \$e"
[16:28:42.407] Install and start server if needed
[16:28:43.395] > Looking for existing server in C:\Users\myusername\.vscode-server-insiders/bin/241d4048aabc31db0baed66bb3d58cf3210d981d
> vscode-server already installed. Skipping download...
> Starting server...
[16:28:43.396] Got some output, clearing connection timeout
[16:28:47.464] > Server did not start successfully. Full server log >>>
> 
> 
> *
> * Visual Studio Code Server
> *
> * Reminder: You may only use this software with Visual Studio family products,
> * as described in the license https://aka.ms/vscode-remote/license
> *
> 
> 
> <<< End of server log
> ad32d7535ad9##32##
[16:28:47.738] "install" terminal command done
[16:28:47.739] Install terminal quit with output: ad32d7535ad9##32##
[16:28:47.739] Received install output: ad32d7535ad9##32##
[16:28:47.742] Resolver error: The VS Code Server failed to start
[16:28:47.750] ------

[ackvf]

What about running the VS Code Server on Host in WSL? Would it work?

PS: Shouldn't it be easier than this https://github.com/microsoft/vscode-remote-release/issues/25#issuecomment-522264179?

[roblourens]

It already "works" but I wouldn't say it's officially supported. But as long as bash is on its PATH, you can connect to a windows machine with WSL available and it will install the VS Code Server into the WSL system and connect to it.

[ackvf]

HEUREKA, IT WORKS NOW. I have no idea why it didn't work 2 days ago and I spent whole day figuring that out, trying various alternatives and hacks.

My current setup is just basic: two Windows 10 computers, and VSCode Insider on local, remote ssh. Nothing more.

original message

I have failed to make it work actually.

On the server, first using Insiders and Windows cmd as ssh terminal, I got an error during the server install that the system is not supported.

Then I set the DefaultShell in the registry of \OpenSSH to the wsl executable.
Running the VSCode on local now correctly connected to the remote wsl shell over ssh and was able to install the server, however, it failed to connect.
So I then tried to run VSCode on server and tried to connect to it's WSL via WSL Remote development extension. It worked well, but doing that from local didn't work again.

[ili101]

It actually works for me:

1. Install the OpenSSH Client Windows Feature on Windows 10.
2. Install the OpenSSH Client and Server Windows Feature on Windows Server 2019.
3. Install VSCode Insiders with the "Remote - SSH (Nightly)" extension.
4. In settings.json add "remote.SSH.remoteIsWindows": true
5. F1/Remote Explorer -> "Remote-SSH: Add New SSH Host..." -> And add your server.

The only things that need improvement is:

1. Make "remote.SSH.remoteIsWindows": true unnecessary by detecting the mode automatically.
2. Add support for OpenSSH "DefaultShell" set to "powershell.exe" and "pwsh.exe" (currently it works only with the default setting which is cmd).
3. Move this to stable so we can use it without VSCode Insiders.

[ackvf]

@ili101 the default ssh shell is configured by OpenSSH and can be set via registry or PowerShell. see here

You can also set an array of windows hosts instead, it's somewhat more flexible if you use multiple hosts. "remote.SSH.windowsRemotes": ["hp", "hpbt"]

[ili101]

@ackvf Thank you for the remote.SSH.windowsRemotes array tip. 👍

Regarding the DefaultShell, I meant that if you change the DefaultShell like it shows in the link you provided to powershell.exe, the VSCode SSH Remote extension will not work any more because it only supports cmd.

[roblourens]

I did some work to improve this, would appreciate anyone trying it out if you are using a Windows remote.

• Install the Nightly version of the extension: https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-ssh-nightly
• Enable "local server mode", set "remote.SSH.useLocalServer": true
• Remove your remote.SSH.windowsRemotes setting which will no longer be necessary

Now when using "local server mode" I try to automatically detect the platform that we are attaching to.

[OneCyrus]

with localserver setting it doesn't work anymore for me. I get the following error. (works with windowsRemotes)

[20:58:35.628] > W[20:58:35.635] > local-server> ssh child died, shutting down
[20:58:35.658] Local server exit: 0
[20:58:35.659] Install terminal quit with output: W[20:58:35.659] Received install output: W[20:58:35.661] Stopped parsing output early. Remaining text: W[20:58:35.661] Failed to parse remote port from server output
[20:58:35.663] Resolver error: 
[20:58:35.667] ------

//edit
ok looks like it doesn't work with windowsRemotes too anymore with the current nightly

[ili101]

Works remoteIsWindows.log
Errors useLocalServer.log

[roblourens]

Does that mean it used to work? Also windowsRemotes is now ignored with "useLocalServer"

Can you share the full log?

[roblourens]

Edit - Ok, now the changes are in 2020.1.31489

Sorry! I tried to publish the extension earlier and actually it didn't go out. Hang on...

[OneCyrus]

looks good. 2020.1.31489 works for me now. thanks!

[ili101]

Detected Windows and Linux automatically 👍.
Can you add OpenSSH DefaultShell set to powershell.exe / pwsh.exe support?

[staticfloat]

Even with my default shell set to cmd.exe, I continue to get the following error:

[14:05:13.639] Log Level: 3
[14:05:13.640] [email protected]
[14:05:13.640] darwin x64
[14:05:13.642] SSH Resolver called for "ssh-remote+win64test", attempt 1
[14:05:13.642] SSH Resolver called for host: win64test
[14:05:13.642] Setting up SSH remote "win64test"
[14:05:13.653] Using commit id "ee803826ad8f16534bbf72fa463306ebcb1e7ee6" and quality "insider" for server
[14:05:13.654] Install and start server if needed
[14:05:13.656] Checking ssh with "ssh -V"
[14:05:13.667] > OpenSSH_7.9p1, LibreSSL 2.7.3
[14:05:13.667] Remote command length: 5868/8192 characters
[14:05:13.668] Running script with connection command: ssh -T -D 64663 -o ConnectTimeout=15 win64test powershell -ExecutionPolicy Unrestricted -NoLogo -NoProfile -NonInteractive -Command "$e=[Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes([Text.Encoding]::UTF8.GetString([Convert]::FromBase64String('CiRQcm9ncmVzc1ByZWZlcmVuY2UgPSAnU2lsZW50bHlDb250aW51ZScKJGNvbW1pdElkID0gJ2VlODAzODI2YWQ4ZjE2NTM0YmJmNzJmYTQ2MzMwNmViY2IxZTd
<snip>
lbHNlIHsKaWYgKCEoZ3BzIC1JZCAkc3NoZFBJRCkpIHsKZWNobyAiVGhlIHNzaGQgcGFyZW50IGRpZWQsIGV4aXRpbmciCmV4aXQgMAp9Cn0KClN0YXJ0LVNsZWVwIDMwCn0K')))); powershell -ExecutionPolicy Unrestricted -NoLogo -NoProfile -NonInteractive -EncodedCommand $e"
[14:05:15.494] > =[Convert]::ToBase64String : The term '=[Convert]::ToBase64String' is not recognized as the name of a cmdlet, 
> function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the 
> path is correct and try again.
> At line:1 char:1
> + =[Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes([Text.En ...
> + ~~~~~~~~~~~~~~~~~~~~~~~~~~
>     + CategoryInfo          : ObjectNotFound: (=[Convert]::ToBase64String:String) [], CommandNotFoundException
>     + FullyQualifiedErrorId : CommandNotFoundException
> 
> PowerShell[.exe] [-PSConsoleFile <file> | -Version <version>]
>     [-NoLogo] [-NoExit] [-Sta] [-Mta] [-NoProfile] [-NonInteractive]
<snip>

This is using VS Code Insiders:

Version: 1.42.0-insider
Commit: ee803826ad8f16534bbf72fa463306ebcb1e7ee6
Date: 2020-01-22T14:43:05.017Z

When I SSH into the server directly, I can confirm that the default shell has been explicitly set to C:\Windows\System32\cmd.exe. (When I installed OpenSSH 8.1.0, the default shell was set to powershell)

$ ssh Administrator@win64test
Microsoft Windows [Version 10.0.17763.973]
(c) 2018 Microsoft Corporation. All rights reserved.

administrator@WIN64TEST C:\Users\Administrator>

If there is any other debugging information I can give you, please do not hesitate to ask. I'd really like to be able to support VSCode remoting into these windows machines!

[roblourens]

@staticfloat it looks like you have not followed the step to set this setting "remote.SSH.useLocalServer": true

[staticfloat]

With that setting enabled, I get even less information:

[15:06:07.950] Log Level: 3
[15:06:07.952] [email protected]
[15:06:07.952] darwin x64
[15:06:07.954] SSH Resolver called for "ssh-remote+win64bot3", attempt 1
[15:06:07.954] SSH Resolver called for host: win64bot3
[15:06:07.954] Setting up SSH remote "win64bot3"
[15:06:07.957] Acquiring local install lock: /var/folders/xz/tg6x2wt15y70nmr5cb0bq2k00000gn/T/vscode-remote-ssh-win64bot3-install.lock
[15:06:07.966] Looking for existing server data file at /Users/sabae/Library/Application Support/Code - Insiders/User/globalStorage/ms-vscode-remote.remote-ssh-nightly/vscode-ssh-host-win64bot3-ee803826ad8f16534bbf72fa463306ebcb1e7ee6/data.json
[15:06:07.967] Using commit id "ee803826ad8f16534bbf72fa463306ebcb1e7ee6" and quality "insider" for server
[15:06:07.968] Install and start server if needed
[15:06:07.972] Checking ssh with "ssh -V"
[15:06:07.986] > OpenSSH_7.9p1, LibreSSL 2.7.3
[15:06:07.989] askpass server listening on /var/folders/xz/tg6x2wt15y70nmr5cb0bq2k00000gn/T/vscode-ssh-askpass-2d15c27484f30b00366df3f5fdefccca8de6a004.sock
[15:06:07.989] Spawning local server with {"ipcHandlePath":"/var/folders/xz/tg6x2wt15y70nmr5cb0bq2k00000gn/T/vscode-ssh-askpass-ee64f62fe275d17c8ebd6e5de9cf5fa9412388e0.sock","sshCommand":"ssh","sshArgs":["-T","-D","49657","-o","ConnectTimeout=15","win64bot3"],"dataFilePath":"/Users/sabae/Library/Application Support/Code - Insiders/User/globalStorage/ms-vscode-remote.remote-ssh-nightly/vscode-ssh-host-win64bot3-ee803826ad8f16534bbf72fa463306ebcb1e7ee6/data.json"}
[15:06:07.989] Local server env: {"DISPLAY":"1","ELECTRON_RUN_AS_NODE":"1","SSH_ASKPASS":"/Users/sabae/.vscode-insiders/extensions/ms-vscode-remote.remote-ssh-nightly-2020.1.31600/out/local-server/askpass.sh","VSCODE_SSH_ASKPASS_NODE":"/Applications/Visual Studio Code - Insiders.app/Contents/Frameworks/Code - Insiders Helper (Renderer).app/Contents/MacOS/Code - Insiders Helper (Renderer)","VSCODE_SSH_ASKPASS_MAIN":"/Users/sabae/.vscode-insiders/extensions/ms-vscode-remote.remote-ssh-nightly-2020.1.31600/out/askpass-main.js","VSCODE_SSH_ASKPASS_HANDLE":"/var/folders/xz/tg6x2wt15y70nmr5cb0bq2k00000gn/T/vscode-ssh-askpass-2d15c27484f30b00366df3f5fdefccca8de6a004.sock"}
[15:06:07.991] Spawned 31521
[15:06:08.080] > local-server> Spawned ssh: 31522
[15:06:09.481] stderr> shell request failed on channel 2
[15:06:09.482] > local-server> ssh child died, shutting down
[15:06:09.487] Local server exit: 0
[15:06:09.488] Install terminal quit with output: shell request failed on channel 2

[15:06:09.488] Received install output: shell request failed on channel 2

[15:06:09.488] Stopped parsing output early. Remaining text: shell request failed on channel 2
[15:06:09.488] Failed to parse remote port from server output
[15:06:09.490] Resolver error: 
[15:06:09.493] ------

(Note that I've changed the hostname, but the deployment is identical)

[roblourens]

shell request failed on channel 2

Uh, no clue. Are you sure that something like echo 'echo hello' | ssh -T -D 49657 -o ConnectTimeout=15 win64bot3 works in an external terminal?

[staticfloat]

No, it doesn't. I get shell request failed on channel 0. Starting up psexec -s sshd.exe -ddd on the server, then watching the server output when I attempt to run that locally, I see the following:

...
Starting session: shell for administrator from fd37:5040::6639:ae1b:3e46:1517 port 50566 id 0
debug2: fd 9 setting O_NONBLOCK
debug2: fd 10 setting O_NONBLOCK
debug2: fd 11 setting O_NONBLOCK
debug2: fd 12 setting O_NONBLOCK
debug2: fd 13 setting O_NONBLOCK
debug2: fd 14 setting O_NONBLOCK
debug3: shell: "c:\\windows\\system32\\cmd.exe"
debug3: shell_option: /c
debug3: exec_command: (null)
debug3: send packet: type 100
Connection closed by fd37:5040::6639:ae1b:3e46:1517 port 50566
debug1: channel 0: free: server-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 server-session (t10 r0 i0/0 o0/0 e[closed]/0 fd -1/-1/-1 sock -1 cc -1)

Close session: user administrator from fd37:5040::6639:ae1b:3e46:1517 port 50566 id 0
debug3: session_unused: session id 0 unused
debug1: do_cleanup
...

This leads me to believe that the issue is that sshd.exe is invoking cmd.exe incorrectly; there's an extra /c being passed to cmd.exe, making it exit immediately. Indeed, if I instead do ssh -T -D 49657 -o ConnectTimeout=15 win64bot3 "echo hello" then it works just fine. Perhaps I need to modify not only the DefaultShell registry option but the DefaultShellCommandOption registry option as well, as briefly mentioned here? I'm not sure what I would set it to however, as it seems like piping a command into ssh should bypass that option alltogether. What is your working configuration?

[roblourens]

That's interesting...

I don't have any of those reg keys set. My output looks different. Here is the only section where cmd.exe appears, and nothing else looks useful:

Starting session: shell for roblou from 131.107.160.94 port 4564 id 0
debug2: fd 9 setting O_NONBLOCK
debug2: fd 10 setting O_NONBLOCK
debug2: fd 11 setting O_NONBLOCK
debug2: fd 12 setting O_NONBLOCK
debug2: fd 13 setting O_NONBLOCK
debug2: fd 14 setting O_NONBLOCK
debug1: Executing command: "c:\\windows\\system32\\cmd.exe" with no pty
debug2: fd 4 setting TCP_NODELAY
debug3: fd 11 is O_NONBLOCK
debug3: fd 10 is O_NONBLOCK
debug3: fd 13 is O_NONBLOCK
debug3: send packet: type 99
debug3: receive packet: type 96
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug2: channel 0: read 0 from efd 13
debug2: channel 0: closing read-efd 13
debug2: notify_done: reading
debug1: Received SIGCHLD.
debug1: session_by_pid: pid 2704
debug1: session_exit_message: session 0 channel 0 pid 2704

The sshd openssh version is 7.7

[staticfloat]

Did you install your OpenSSH from https://github.com/PowerShell/Win32-OpenSSH/releases ?

[roblourens]

No, it came with windows 10

[dragonwolf83]

Looks like the built-in Windows 10 version is a few releases behind then from the latest release, v8.1.0.0p1-Beta. Most likely it is in 20H1 if any Windows Insiders want to check.

v7.9.0.0p1-Beta introduced these changes that likely is causing the issue:

Rich command-line support for various shells including powershell, bash and cygwin (#1082 and #1211). Check here for usage.

[bersbersbers]

Looks like the built-in Windows 10 version is a few releases behind then from the latest release, v8.1.0.0p1-Beta.

It certainly is!

Most likely it is in 20H1 if any Windows Insiders want to check.

Correct, see https://github.com/PowerShell/Win32-OpenSSH/issues/1263#issuecomment-571846198

We are shipping the latest github version (v8.1.0.0) into next windows release.

[roblourens]

I will try to get that set up on a machine to test but if that simple command above doesn't work, could you please open an issue on the windows ssh repo for it?

[staticfloat]

I can confirm that backing down to the 7.7.2.0p1-Beta release works! I'll be deploying that version on my servers for now. Thanks for the working datapoint!

[TylerLeonhardt]

Just wanted to tag @bagajjal & @manojampalam on the Windows OpenSSH side in case you need to talk to one of them.

[staticfloat]

Also, for anyone else here that loves their bash on windows but still wants to be able to use VSCode remote, the workaround I have currently setup is to use an autorun.cmd deployed on the servers that detects when an SSH connection is coming in and has a terminal allocated:

@echo off

if defined SSH_CLIENT (
    :: check if we've got a terminal hooked up; if not, don't run bash.exe
    C:\cygwin\bin\bash.exe -c "if [ -t 1 ]; then exit 1; fi"
    if errorlevel 1 (
        C:\cygwin\bin\bash.exe --login
        exit
    )
)

This is known to work with Cygwin bash, unsure about bash that ships with windows; I imagine it's very sensitive to how the TTY code works internally. This way, launching cmd.exe works normally, using VSCode (because it does not allocate a PTY) works normally, but SSH'ing into the machine launches bash.exe.

[Keno]

Using older SSH versions works, but it's quite unsatisfying because these older versions don't work nearly as well for the interactive use case. Were you able to reproduce the issue with the newer SSH versions/any idea where the problem is?

[ewired]

Hey, thanks for all your work on this feature. One small thing that might impact release for some users: I noticed that the method of running the initial script was to call powershell.exe with an encoded command. Is there any different way or any way I can manually run this procedure to get the server up on my Windows machine? It turns out that Cisco AMP flags the encoded command as a malware technique and it then appears to kill the process.

[roblourens]

@ewired that's unfortunate, it's hard for me to avoid. Do you know of any way to configure Cisco AMP to not do that? I guess I will have to wait and see how common this is.

[roblourens]

With the next release, we will allow using windows remotes with stable vscode 😁

[JustinGrote]

I can confirm same as @staticfloat. If I try 8 or 8.1 beta on the server I get
https://github.com/microsoft/vscode-remote-release/issues/18#issuecomment-594277035. Will open as new issue.