VSCode Remote: Connect to WSL2 from another machine

remote-wsl.md

VSCode Remote: Connect to WSL2 from another machine

Do you want to do remote development on your WSL2 container in Visual Studio Code? Read this.

Proxy jump method

1. On the host set up OpenSSH for Windows
2. Run wsl --update to make sure you are running the latest WSL
3. Open WSL and install another SSH server inside WSL with sudo apt-get install openssh-server
4. Now run sudo systemctl enable --now ssh to automatically start ssh when WSL starts.
5. On the remote machine run ssh -J windows_user@windows_ip wsl_user@localhost to see if the proxy jump will work

If you see the bash prompt it works. You can add it to the ~/.ssh/config file on the remote machine.

Host remote-wsl
  HostName localhost
  User wsl_user
  ProxyJump windows_user@windows_ip
  StrictHostKeyChecking no

Now connect with ssh remote-wsl.

Credit

ajihyf's comment

Default shell method

Change your OpenSSH shell

SSH to your Windows host (SSH Server must be installed in Windows Features)

ssh user@windowshost

Start Powershell

powershell

Run this command to switch SSH from CMD to WSL

New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\WINDOWS\System32\bash.exe" -PropertyType String -Force

Test

ssh user@windowshost

You should now see WSL2 instead of CMD

Connect from VSCode

At this point you can connect to your Win10 host with Remote SSH in VSCode with your Windows username and pw. But you'll actually start and connect to WSL2.

1. Install the Remote - SSH extension
2. Add a new SSH target and connect with your Windows host, username and password (you will automatically log in as the Linux user)

Credit

The workaround was inspired by: https://www.hanselman.com/blog/the-easy-way-how-to-ssh-into-bash-and-wsl2-on-windows-10-from-an-external-machine

I'm not yet fully convinced myself, but you only need to change remote.SSH.remotePlatform for your Windows host to Linux.
What I mean is that you don't have to change DefaultShell .
Then Remote-SSH will recognize the situation and automatically launches wsl before making handshake with vscode-server.
Then Remote-SSH will connect to Windows host with something like ssh -t {hostname} bash . This will effectively launch wsl by executing C:\Windows\System32\bash.exe .
At least that it how I understand it. You may also need WSL extension installed, not sure.
You need either of wget or curl installed in your wsl env.

I got access denied. Instead I just ran openssh within wsl2 on port 2222 and did this from within powershell.

netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=2222 connectaddress=127.0.0.1 connectport=2222

I then just ssh to port 2222 and it's forwarded to the wsl2 version of openssh.

Latest WSL2 has systemctl support and can automatically map sshd's connection to the Windows host. No need to redirect port.

1. Make sure Windows OpenSSH works.
2. In windows, run wsl --update to make sure use latest WSL.
3. In WSL, run sudo apt-get install openssh-server to install ssh and sudo systemctl enable --now ssh to automatically start ssh when WSL starts.
4. Run ssh -J windows_user@windows_ip wsl_user@localhost to login to ssh
5. If step 4 works, add the following content to .ssh/config

Host wsl
  HostName localhost
  User wsl_user
  ProxyJump windows_user@windows_ip
  StrictHostKeyChecking no
  UserKnownHostsFile=/dev/null

6. Connect to wsl remote in VSCode 🎉🎉🎉

Latest WSL2 has systemctl support and can automatically map sshd's connection to the Windows host. No need to redirect port.

1. Make sure Windows OpenSSH works.
2. In windows, run wsl --update to make sure use latest WSL.
3. In WSL, run sudo apt-get install openssh-server to install ssh and sudo systemctl enable --now ssh to automatically start ssh when WSL starts.
4. Run ssh -J windows_user@windows_ip wsl_user@localhost to login to ssh
5. If step 4 works, add the following content to .ssh/config

Host wsl
  HostName localhost
  User wsl_user
  ProxyJump windows_user@windows_ip
  StrictHostKeyChecking no
  UserKnownHostsFile=/dev/null

6. Connect to wsl remote in VSCode 🎉🎉🎉

This ☝️ ☝️ ☝️ ☝️ Thank you @ajihyf so much!

So much simpler than the other solutions out there.

Thanks a lot, works perfectly!

Latest WSL2 has systemctl support and can automatically map sshd's connection to the Windows host. No need to redirect port.

1. Make sure Windows OpenSSH works.
2. In windows, run wsl --update to make sure use latest WSL.
3. In WSL, run sudo apt-get install openssh-server to install ssh and sudo systemctl enable --now ssh to automatically start ssh when WSL starts.
4. Run ssh -J windows_user@windows_ip wsl_user@localhost to login to ssh
5. If step 4 works, add the following content to .ssh/config

Host wsl
  HostName localhost
  User wsl_user
  ProxyJump windows_user@windows_ip
  StrictHostKeyChecking no
  UserKnownHostsFile=/dev/null

6. Connect to wsl remote in VSCode 🎉🎉🎉

This ☝️ ☝️ ☝️ ☝️ Thank you @ajihyf so much!

So much simpler than the other solutions out there.

Can confirm. This is working like a charm for me as well.

How I proceed with connection to WSL2 on remote host.

1. I've set up OpenSSH server on Windows remote host.
2. From vscode on local machine i connected to remote Windows host.
3. While connecting to remote host using SSH select Windows operating system.
4. After succesful connection to remote Windows host press Ctrl-Shift-P on keyboard, write WSL in opened bar and select WSL: Connect to WSL using Distro in New Window...
5. Distros of remote Windows host will be listed in dropdown menu.
6. Select your distro in dropdown menu
7. Connection to remote WSL distro will start in new window.

Result of connection to remote WSL through ssh

I think it's worth mentioning that I do not have Debian WSL distro on my local machine. This is WSL distro of remote Windows host.

Latest WSL2 has systemctl support and can automatically map sshd's connection to the Windows host. No need to redirect port.

1. Make sure Windows OpenSSH works.

2. In windows, run `wsl --update` to make sure use latest WSL.

3. In WSL, run `sudo apt-get install openssh-server` to install ssh and  `sudo systemctl enable --now ssh` to automatically start ssh when WSL starts.

4. Run `ssh -J windows_user@windows_ip wsl_user@localhost` to login to ssh

5. If step 4 works, add the following content to `.ssh/config`

Host wsl
  HostName localhost
  User wsl_user
  ProxyJump windows_user@windows_ip
  StrictHostKeyChecking no
  UserKnownHostsFile=/dev/null

6. Connect to `wsl` remote in VSCode 🎉🎉🎉

This works so well for me, thanks a lot!!

You don't necessarily need these things anymore. It's possible to use Remote-Tunnels together with the WSL extension on the remote.

@jhanschoo I guess you are referring to VS Code. The solutions here show the generic approach which do not require you to use VS Code.

Thanks, I nevertheless think it's important to note easy solutions when they exist that involve VSCode considering that the topic of the Gist is wrt VSCode. I'm personally aware of the more generic situations but don't use them due to the effort.

IT in my company block vscode remote tunnel (by blocking all the msft remote tunnel servers) saying it evades proxy setting. Guess it is the same for many others so the generic way is still very relevant even for vscode

Ironically, I've ended up mainly using the ProxyJump method today as well, because I have been making extensive use of an extension that launches a server and the extension on the client VSCode instance listens to localhost on the client environment. This works alright when

1. The Remote-SSH extension is in use, connected to within WSL and ports are forwarded from WSL through the SSH connection, managed by the extension.
2. The WSL extension is in use, and the ports are forwarded by WSL to the Windows host (despite showing stuff in the Ports pane, the WSL extension actually does not do any forwarding on its own).

But an issue is encountered when WSL-extension-in-Remote-SSH-extension (or Remote-Tunnels) is used, in which case

• The server residing in WSL is exposed to the host Windows WSL automatically.
• Requests made either to localhost on the client environment, or (iirc) to localhost on the host environment seem to fail to reach the WSL environment intermittently. This was observed by amateurish wireshark monitoring on all three environments. There seems to be a pattern that may be reproducible, but I did not pursue this further.