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 (PowerShell/Win32-OpenSSH#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.)

[zbynekwinkler]

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

[ljrk0]

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.

   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.

      {
          "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.

[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] remote-ssh-nightly@2020.1.31489
[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] remote-ssh-nightly@2020.1.31600
[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 PowerShell/Win32-OpenSSH#1263 (comment)

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
#18 (comment). Will open as new issue.