SSH can‘t Connect to WSL2 from another machine

[awohaoa]

Version

0.70.0.0

WSL Version

• WSL 2
• WSL 1

Kernel Version

5.15.68.1

Distro Version

Ubuntu20.04

Other Software

No response

Repro Steps

In the wsl version( 0.66.2.0), I can perform the following operations to achieve the purpose of accessing wsl2 through ssh

1. Change your OpenSSH shell
   SSH to your Windows host (SSH Server must be installed in Windows Features)
   ssh user@windowshost
2. Start Powershell
   powershell
3. 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
4. You should now see WSL2 instead of CMD
   ssh user@windowshost

But now that I have upgraded to version(0.70.0.0), this operation no longer connects to wsl2

[12:52:03.686] SSH Resolver called for "ssh-remote+192.168.1.72", attempt 5, (Reconnection)
[12:52:03.687] SSH Resolver called for host: 192.168.1.72
[12:52:03.688] Setting up SSH remote "192.168.1.72"
[12:52:03.689] Using commit id "fad3a77833b9249158dfd88477114a06435e46a2" and quality "insider" for server
[12:52:03.691] Install and start server if needed
[12:52:07.269] Running script with connection command: ssh -T -D 58369 "192.168.1.72" bash
[12:52:07.271] Terminal shell path: C:\WINDOWS\System32\cmd.exe
[12:52:08.399] > mems@192.168.1.72's password:�]0;C:\WINDOWS\System32\cmd.exe�
[12:52:08.399] Got some output, clearing connection timeout
[12:52:08.400] Showing password prompt

I thought I set bash as the default shell, but I found that setting bash as the default shell is no longer valid after the updated version

Expected Behavior

I was referring to this link for the purpose I wanted
VSCode Remote: Connect to WSL2 from another machine

Actual Behavior

Now that I have upgraded to version(0.70.0.0), this operation no longer connects to wsl2

Diagnostic Logs

C:\Users\mems>ssh -v mems@192.168.1.72
OpenSSH_for_Windows_8.6p1, LibreSSL 3.4.3
debug1: Reading configuration data C:\\Users\\mems/.ssh/config
debug1: C:\\Users\\mems/.ssh/config line 1: Applying options for 192.168.1.72
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to 192.168.1.72 [192.168.1.72] port 22.
debug1: Connection established.
debug1: identity file C:\\Users\\mems/.ssh/id_rsa type -1
debug1: identity file C:\\Users\\mems/.ssh/id_rsa-cert type -1
debug1: identity file C:\\Users\\mems/.ssh/id_dsa type -1
debug1: identity file C:\\Users\\mems/.ssh/id_dsa-cert type -1
debug1: identity file C:\\Users\\mems/.ssh/id_ecdsa type -1
debug1: identity file C:\\Users\\mems/.ssh/id_ecdsa-cert type -1
debug1: identity file C:\\Users\\mems/.ssh/id_ecdsa_sk type -1
debug1: identity file C:\\Users\\mems/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file C:\\Users\\mems/.ssh/id_ed25519 type -1
debug1: identity file C:\\Users\\mems/.ssh/id_ed25519-cert type -1
debug1: identity file C:\\Users\\mems/.ssh/id_ed25519_sk type -1
debug1: identity file C:\\Users\\mems/.ssh/id_ed25519_sk-cert type -1
debug1: identity file C:\\Users\\mems/.ssh/id_xmss type -1
debug1: identity file C:\\Users\\mems/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_for_Windows_8.6
debug1: Remote protocol version 2.0, remote software version OpenSSH_for_Windows_8.6
debug1: compat_banner: match: OpenSSH_for_Windows_8.6 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.1.72:22 as 'mems'
debug1: load_hostkeys: fopen C:\\Users\\mems/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:9YTeeXvvXZv+IRjWZ5VFdzJ9R4NkEeXbqrJWe6lnEQo
debug1: load_hostkeys: fopen C:\\Users\\mems/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts2: No such file or directory
debug1: Host '192.168.1.72' is known and matches the ED25519 host key.
debug1: Found key in C:\\Users\\mems/.ssh/known_hosts:1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: pubkey_prepare: ssh_get_authentication_socket: No such file or directory
debug1: Will attempt key: C:\\Users\\mems/.ssh/id_rsa
debug1: Will attempt key: C:\\Users\\mems/.ssh/id_dsa
debug1: Will attempt key: C:\\Users\\mems/.ssh/id_ecdsa
debug1: Will attempt key: C:\\Users\\mems/.ssh/id_ecdsa_sk
debug1: Will attempt key: C:\\Users\\mems/.ssh/id_ed25519
debug1: Will attempt key: C:\\Users\\mems/.ssh/id_ed25519_sk
debug1: Will attempt key: C:\\Users\\mems/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,webauthn-sk-ecdsa-sha2-nistp256@openssh.com>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: C:\\Users\\mems/.ssh/id_rsa
debug1: Trying private key: C:\\Users\\mems/.ssh/id_dsa
debug1: Trying private key: C:\\Users\\mems/.ssh/id_ecdsa
debug1: Trying private key: C:\\Users\\mems/.ssh/id_ecdsa_sk
debug1: Trying private key: C:\\Users\\mems/.ssh/id_ed25519
debug1: Trying private key: C:\\Users\\mems/.ssh/id_ed25519_sk
debug1: Trying private key: C:\\Users\\mems/.ssh/id_xmss
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
mems@192.168.1.72's password:
debug1: Authentication succeeded (password).
Authenticated to 192.168.1.72 ([192.168.1.72]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: filesystem full
debug1: ENABLE_VIRTUAL_TERMINAL_INPUT is supported. Reading the VTSequence from console
debug1: ENABLE_VIRTUAL_TERMINAL_PROCESSING is supported. Console supports the ansi parsing
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: client_input_hostkeys: searching C:\\Users\\mems/.ssh/known_hosts for 192.168.1.72 / (none)
debug1: client_input_hostkeys: searching C:\\Users\\mems/.ssh/known_hosts2 for 192.168.1.72 / (none)
debug1: client_input_hostkeys: hostkeys file C:\\Users\\mems/.ssh/known_hosts2 does not exist
debug1: client_input_hostkeys: no new or deprecated keys from server
debug1: ssh_get_authentication_socket: No such file or directory
The file cannot be accessed by the system.
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
Connection to 192.168.1.72 closed.
Transferred: sent 2032, received 2688 bytes, in 0.1 seconds
Bytes per second: sent 25999.3, received 34392.8
debug1: Exit status 0

[OneBlue]

Thank you for reporting this @awohaoa.

Unfortunately, this is a known limitation of store WSL. At the moment it's not possible to access wsl from session 0 (which is where the Windows OpenSSH server run).

[awohaoa]

@OneBlue
Why did the previous version(0.66.2.0) work, and will this access be supported in the future?

[fredyfx]

Related:
#8985
#8907

[NotTheDr01ds]

Why did the previous version(0.66.2.0) work?

This has actually been "broken" (a.k.a. a known limitation) in every Store release since they first started doing them back in October of last year with 0.47.1.0 and was noted in the initial Devblog announcement.

I just uninstall 0.70.5 to test, since you said 0.66.2 was working.

• After uninstalling 0.70.5 and returning to the "in box" version of WSL on Windows 11, ssh into WSL worked.
• Installing 0.66.2 immediately caused it to stop working again.

Is it possible that you didn't actually have 0.66.2 installed when it was working? You might want to retest yourself -- It's quite easy to switch around versions at will without even needing to reboot. Just make sure you verify the release with wsl --version and/or wsl --status.

will this access be supported in the future?

Dang, I sure hope so -- This was an incredibly useful capability, and WSL feels a bit hampered without it. I've been assuming this is a Windows limitation with the way that Store apps are launched, which had me thinking that Windows 11 22H2 would provide a solution for it. But alas, no -- It's still not working on 22H2.

[Tom-E]

+1, it's strange that we take one step forward and one step back.
I was excited to get this: https://devblogs.microsoft.com/commandline/systemd-support-is-now-available-in-wsl/
Yet baffled that this was real + my experience as well: https://superuser.com/questions/1714736/cannot-run-wsl2-over-ssh-on-windows-11

[sinking-point]

@NotTheDr01ds How do you switch around versions? The --rollback option doesn't seem to exist anymore. If I uninstall and then reinstall a different version of WSL2, will my existing distributions be deleted?

[joes]

@NotTheDr01ds

As a workaround for now it is possible to install and run a second OpenSSH server (using a different port) in your WSL instance.

This can then be combined with using the ProxyJump directive to transparently connect to the second OpenSSH server running in the wsl instance by jumping through the win32 OpenSSH server. The directive can be added to the remote system's ~/.ssh/config:

Host openssh_win32
    Hostname your_computer.local
    User windows_username

Host openssh_wsl
   ProxyJump openssh_win32
   User wsl_username
   HostName localhost
   Port 2222

The above example assumes that the second OpenSSH server in wsl is running on port 2222.

Using this configuration it is then possible to connect to the wsl instance via the hostname openssh_wsl:

ssh openssh_wsl

As always, YMMV.

[carljwhite3]

Does joes work around only work if have WSL instance already running?

[joes]

@carljwhite3

It would require the wsl instance to be running prior to connecting to it. This workaround would not be able to start the wsl instance.

[NotTheDr01ds]

@NotTheDr01ds

As a workaround for now it is possible to install and run a second OpenSSH server (using a different port) in your WSL instance.

Agreed - I posted that technique on Super User a bit over a year ago, and yes, jumphosts are super useful for WSL, especially when I was using Ansible to configure WSL distributions over SSH. It was a whole lot more useful when you could also start the WSL instance remotely, especially since I have typically have somewhere upwards of 12 distributions installed. ;-)

[carljwhite3]

Launching a instance of WSL remotely worked previously and was very convenient. Bascily, you would have the Windows Open SSH instance running and then you could jump into a WSL instance from there.

[astanziola]

Is there any update on this?

[ghost]

Is there any update on this?

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!