

- #Debian enable ssh install#
- #Debian enable ssh update#
- #Debian enable ssh full#
- #Debian enable ssh password#
There is nothing extra to do to make this port reachable to outside connections. As a result, the SSH server that is listening on port 2022 within WSL is actually listening on port 2022 of the physical interface. WSL 1 shares the kernel facilities with Windows so the network interface we see within WSL 1 is the physical network interface of the machine. You may want to review my post titled Windows Subsystem for Linux: The lost potential for details on this topic-and yes, I still believe WSL 1 is a better model. Its contents vary depending on WSL 1 and WSL 2 because they are vastly different beasts network-wise. It’s time to populate the sshd.bat script with the actual logic to run WSL and SSH. With these steps done, the task is now ready to run at system startup time even if you don’t log into your account.

In the Actions tab, fix the path in the Start a program action so that it points to the sshd.bat script you created: Screenshot of the Actions tab contents in the task configuration.

Just make sure the trigger is registered as At startup: Screenshot of the Triggers tab contents in the task configuration. In the Triggers tab, you should not have to change anything. In the General tab, click on Change User or Group… and fix the name of the Windows user that will launch WSL: Screenshot of the General tab contents in the task configuration.
#Debian enable ssh update#
Now edit the task to update the few settings that are machine- and user-dependent. Open the Task scheduler tool from the Start menu.Ĭlick on the Import Task… action and select the XML file you created. Proceed with these fake values during the initial import. In particular, UserId and Command are wrong for your machine. WARNING: Beware that this task definition relies on machine- and user-specific properties, and that I wiped them in the file above.
#Debian enable ssh password#
T16:32:19.159532 CHERRY\jmmv \Start WSL SSH true PT30S S-0-0-00-0000000000-0000000000-0000000000-0000 Password LeastPrivilege IgnoreNew true true true false false true false true true false false false PT72H 7 C:\Users\youruser\sshd.bat The instructions here are based on Debian.
#Debian enable ssh install#
Install WSL and a Linux distribution, and choose whether you want to use version 1 or 2. Let’s start by configuring the SSH server within WSL: The majority of the configuration process is common between WSL 1 and WSL 2, so let’s do those common steps first. The goal configuration in this post is to have an SSH server on port 2022 to reach WSL and to have it readily available when the machine boots (because reboots can unfortunately happen at any time “thanks to” forced OS updates). The process is tricky though and depends on the WSL version in use, so you can take these as my lab notes set this whole ordeal up.

Could VSCode leverage this connection to directly interact with WSL from my laptop when on-the-go?.Could I configure Windows so that incoming SSH connections went to WSL?.Windows has WSL, which had proven to be sufficient for my needs, but WSL is still a separate environment from Windows-and the distinction rears its ugly head when trying to remote into the machine. I knew that Windows ships with an SSH server and that it works well with VSCode, but I am still much more comfortable developing my side projects on a Unix system.
#Debian enable ssh full#
Moving to Windows full time, as I briefly touched upon in My story with Windows, required that I could do the same on this platform. Thanks to this, it’s trivial to set up an SSH server to remotely access and administer the machine, which in turn has allowed me to have a nice and powerful desktop computer which I can also leverage when I’m on the go. One of the reasons I like macOS is that it is a Unix system.
