Connect to WSL via SSH on macOS

[vilicvane]

In the 1.89 release note, it states that it's now possible to connect to WSL via SSH. But I cannot get it work on macOS.

Is it supported anyway?

[ntrogh]

@vilicvane Are you able to connect to your Windows machine over SSH?

[vilicvane]

Yes.

[ntrogh]

When you then open the terminal, does it not show a WSL session?

[vilicvane]

@ntrogh It shows PowerShell. Should I do something to enter WSL?

[ntrogh]

In the terminal panel, can you use the dropdown to select WSL?
Also, do you have WSL enabled on that Windows machine and is there a Linux distro installed on it?

[vilicvane]

@ntrogh I’ll check the dropdown later. And yes, currently I am using SSH server running on WSL.

[juaoose]

Something similar happens to me:

• SSH from Mac to the Windows machine.
• Only the regular terminals show in the dropdown (powershell, cmd.exe, js debug terminal)
• On the remotes tab, it shows the windows machine in green as that what I'm connected to.
  Is there any guidance on how one should use this? The only "how to" I found was literally this issue mentioning to look at the terminals dropdown. (The release notes linked to other release notes that were not very helpful)

[ntrogh]

@connor4312, are there specific setup instructions for this to work on macOS?

[ntrogh]

@juaoose Added an issue to update the docs

[connor4312]

Yes, this is supported. You need the WSL extension installed, and then WSL in the Remote Explorer will be populated and you can use the usual "reopen in WSL" commands.

[juaoose]

Yes, this is supported. You need the WSL extension installed, and then WSL in the Remote Explorer will be populated and you can use the usual "reopen in WSL" commands.

Interesting, after connecting via SSH (in VSCode), the WSL Targets doesn't show anything. Is there any extra setup required?

[connor4312]

What version of WSL do you have installed on the Windows machine?

[juaoose]

$ wsl --version
WSL version: 2.1.5.0
Kernel version: 5.15.146.1-2
WSLg version: 1.0.60
MSRDC version: 1.2.5105
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22631.3593

[connor4312]

Can you run the WSL: Show Log command when connected over remote SSH?

[juaoose]

[2024-05-28 16:47:23.517] Extension version: 0.88.2
[2024-05-28 16:47:23.517] L10N bundle: undefined
[2024-05-28 16:47:23.525] authorityHierarchy: ssh-remote+100.74.137.59
[2024-05-28 16:47:23.525] WSL extension is activating remotely for ssh-remote+100.74.137.59
[2024-05-28 16:47:23.542] Workspace platform is Windows
[2024-05-28 16:47:23.552] Run: C:\WINDOWS\System32\wsl.exe --status
[2024-05-28 16:47:23.700] WSL feature installed: false (wsl --status)
[2024-05-28 16:47:23.700] WSL feature installed: false
[2024-05-28 16:47:31.310] Run: C:\WINDOWS\System32\wsl.exe --list --verbose
[2024-05-28 16:47:31.396] Error: Failed to run wsl.exe --list --verbose: error code 1, error: The file cannot be accessed by the system.

[connor4312]

You should be able to resolve this by installing the latest version of WSL from their msi installer available at https://github.com/microsoft/WSL/releases/tag/2.1.5

[juaoose]

Hmmm I'm not sure I can risk that installation atm.

On a note: I verified those paths mentioned in the logs... it looks like my WSL is in "C:/Program Files/WSL/wsl.exe" and not in system32? Is there no way to make the extension use that?

[vilicvane]

@connor4312 My log shows similar, and I tried to execute wsl command in the PowerShell (remotely connected via VSCode):

PS C:\Users\vilicvane> C:\WINDOWS\System32\wsl.exe
The file cannot be accessed by the system.

Directly run this command in Windows PowerShell:

PS C:\Users\vilicvane> C:\WINDOWS\System32\wsl.exe --status
Default Distribution: Ubuntu
Default Version: 2

I have also tried the msi installer, although my WSL was already the latest version. After running the msi installer, it prompted for Administrator privilege and then did nothing.

[vilicvane]

@connor4312 I think it might relate to this microsoft/WSL#8072 and this comment may be a workaround.