How to run sshd as a windows service ?

[imjakey]

Steps to reproduce:

step 1:
start bash

step 2: start sshd server sudo /etc/init.d/ssh start

step 3: connected to sshd server from xshell (a powerful terminal emulator which better than windows cmd line). if you don't have xshell , use putty or any other client instead

step 4: closed the bash cmd window , xshell connection is also closed.

Question: how do I run sshd as a windows service ?

thanks !

[fpqc]

I would suggest instead running urxvt in xming, because sshd needs to be run as root, and there are annoying problems that can arise with that.

Right now there is no support for running daemons as windows services because WSL is meant for developer workstations rather than servers, although some unprivileged daemons (like urxvtd) can be run silently with a little bit of workaround.

[therealkenc]

That is not even remotely accurate. There are no annoying problems with running sshd as root (sudo service ssh start); and even if there were, you can run sshd on an unprivileged port no different than urxvtd. For people uninterested in inviting all of X11 to the party, PuTTY and a dozen other SSH clients are lighter weight and make more sense. I use the Chrome Secure Shell Extension. Indeed, X clients have been explicitly identified as low priority for the WSL project, but do run, happily, as a side effect of coincidental socket and pty improvements.

[fpqc]

Yeah, but I run urxvtd on startup with run.exe, whereas to start the sshd service you have to type a p/w (because you are sudoing it "superuser do", i.e. running it as the root user). I have a shortcut that does

run.exe bash.exe -c "urxvtd -q -o -f ; bash"

in the startup folder for my Windows user (in addition to running Xming on startup), so I can launch urxvtc whenever I want, with the daemon running totally silently with bash.exe -c urxvtc

I'm not saying you can't run sshd, just that you can't do it silently so it "appears like" a Windows service, and the reason why is that you have to type in your sudo password.

Sure, I guess you could get around this maybe with some kind of batch file that types in your sudo password?

[aseering]

Or you could modify your sudoers file to not require a password for that command.

[fpqc]

Yeah, that works too! Good idea!

Edit: How did you do it? I set NOPASSWD mode for /bin/service and it still asks me for a pw.

[aseering]

Make sure you have the syntax right? Test it on an actual Ubuntu machine if you have one available; the sudoers file format can be finicky to get right.

(Disclaimer: I haven't actually tried this particular command. I've run other commands with passwordless sudo under WSL, though.

[fpqc]

@therealkenc @aseering, @Manouchehri says in the cmake thread that you also need to star the sshd service in a bash.exe terminal that also has Windows admin credentials in order to open up a socket for sshd. Have you guys found a way around that?

[Manouchehri]

Can a normal user can ever bind on a system port on Windows?

[fpqc]

@Manouchehri I think so. Bittorrent clients can, and they can even make UPnP requests, I think.

[Manouchehri]

BitTorrent (shouldn't) run on system ports (0-1024). Most clients bind on a UDP port in the dynamic port range.

[aseering]

@fpqc -- could you run on a higher port? The problem is that the default sshd port is in the system-port range, as @Manouchehri said. I often bind servers to port 2222, or some other higher-numbered port, to work around that limitation.

[therealkenc]

@fpqc, I'm not running WSL in terminal with Windows admin privileges. It binds to 22 fine with sudo service ssh start or however you feel like starting the daemon. You can also start it on 2222 like @aseering says, but there's a minor issue with perms on /dev/tty so you still have to run it as root.

[Manouchehri]

@therealkenc Permission issues on the Windows or Linux side? /dev/tty shows as owned by the user to me.

ubuntu@DESKTOP-3RQO5S5:~$ ls -l /dev/tty
crw------- 1 ubuntu tty 4, 1 Jul  2 22:23 /dev/tty

[fpqc]

@therealkenc It seems to work for me too doing that, but I have a problem connecting to it with PuTTY, and if I open another terminal and try to connect it appears to connect but then dies.

fpqc@FPQC-PC:~|⇒  ssh -vvv 127.0.0.1 
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 127.0.0.1 [127.0.0.1] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/fpqc/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home/fpqc/.ssh/id_rsa type 1
debug1: identity file /home/fpqc/.ssh/id_rsa-cert type -1
debug1: identity file /home/fpqc/.ssh/id_dsa type -1
debug1: identity file /home/fpqc/.ssh/id_dsa-cert type -1
debug1: identity file /home/fpqc/.ssh/id_ecdsa type -1
debug1: identity file /home/fpqc/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/fpqc/.ssh/id_ed25519 type -1
debug1: identity file /home/fpqc/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.7
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.7
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.7 pat OpenSSH_6.6.1* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "127.0.0.1" from file "/home/fpqc/.ssh/known_hosts"
debug3: load_hostkeys: loaded 0 keys
debug1: SSH2_MSG_KEXINIT sent
Connection closed by 127.0.0.1

[Manouchehri]

Looks like we actually can bind to 22/TCP without Windows admin privs?

ubuntu@DESKTOP-3RQO5S5:~$ sudo strace netcat -l -p22 -w5
sudo: unable to resolve host DESKTOP-3RQO5S5
execve("/bin/netcat", ["netcat", "-l", "-p22", "-w5"], [/* 14 vars */]) = 0
brk(NULL)                               = 0x1441000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
# ...snip...
brk(0x1462000)                          = 0x1462000
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(3, {sa_family=AF_INET, sin_port=htons(22), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
listen(3, 1)                            = 0
accept(3, {sa_family=AF_INET, sin_port=htons(16627), sin_addr=inet_addr("127.0.0.1")}, [16]) = 4
close(3)                                = 0
poll([{fd=4, events=POLLIN}, {fd=0, events=POLLIN}], 2, 5000) = 1 ([{fd=4, revents=POLLIN}])
read(4, "Yep, this works.\n", 2048)     = 17
write(1, "Yep, this works.\n", 17Yep, this works.
)      = 17
poll([{fd=4, events=POLLIN}, {fd=0, events=POLLIN}], 2, 5000) = 0 (Timeout)
close(4)                                = 0
close(3)                                = -1 EBADF (Bad file descriptor)
close(3)                                = -1 EBADF (Bad file descriptor)
exit_group(0)                           = ?
+++ exited with 0 +++

[therealkenc]

@Manouchehri - I see what's going on with my /dev/tty now. I start bash.exe with user root and then su ken in root's .bashrc. WSL seems to set the /dev/tty owner to the bash.exe user. So my /dev/tty is root:tty not ubuntu:tty. But the real problem is perms 600 instead of 666. Anyway you can set phasers on ignore here. sshd on 2222 will work just fine as user ubuntu if you start bash.exe as user ubuntu.

@fpqc - dunno what exactly is going on there. I just followed the secret handshake in #300 and never really looked back since then. In short:

ListenAddress 0.0.0.0
UsePrivilegeSeparation no
PasswordAuthentication yes

[fpqc]

@therealkenc Yeah that works, but any idea why adding my PuTTY key to known_hosts doesn't allow me to connect password-free from PuTTY?

[therealkenc]

Follow these instructions (or others like it) and you should be good.

[qris]

I was able to make sshd run automatically as a foreground task, but only after login. After many failed attempts I set my computer to login automatically as the user I wanted. Here is the process that I used:

Add the following line to /etc/sudoers (using sudo visudo for safety):

%sudo ALL=(ALL) NOPASSWD: /usr/sbin/sshd -D

And then use the Task Scheduler to create a new basic task with these settings:

• Run: When the computer starts,
• Action: Start a program,
• Program: c:\Windows\system32\bash.exe,
• Arguments: -c "sudo /usr/sbin/sshd -D"

Test it by clicking on the Task Scheduler LIbrary, selecting your new task and clicking Run on the right-hand side. A command prompt window should open and remain open.

If you want to hide the window, I think you can tick the Hidden box in the scheduled task properties.

[fpqc]

@qris I would also suggest running it with run.exe (available on the xming project page) to hide the console if necessary.

[imjakey]

Thank you everyone, you have helped me a lot.

I use two scripts to achieve my goals:

script 1 named startssh.bat, the contents is : cd C:\Windows\System32 bash.exe -c "/usr/sbin/sshd -D"

script 2 named autostartssh.vbe, the contents is : set ws=wscript.createobject("wscript.shell") ws.run "startssh.bat /start",0

the script 2 can run script 1 like a deamon, then I add scipt 2 to a Windows Task Scheduler, it will run on the computer starts. Now, I can connected to my sshd server from xshell, it works well !

[rodrymbo]

@qris - When I change the setting to "Run whether the user is logged in or not," the task no longer starts, (at least when I click on it and choose "Run"). It works fine when set to "Run only when user is logged on". Any thoughts? Can anyone else replicate this behavior in Task Scheduler, or make a task start properly with "whether user is logged on or not"?

[qris]

@fpqc @rodrymbo Sorry, I posted my comment too soon. My suggestion of running the process regardless of whether the user is logged in or not did not work, as you discovered, and I have not been able to make it work. I have edited my post to avoid suggesting this option.

[jaydenn]

Thanks for the help, but I'm having an odd problem.. When I try to ssh in from my remote ubuntu laptop, it does not recognize my credentials. However, somehow it recognizes my windows user credentials, and when I ssh in I am dropped into a cmd shell - not bash.. I'm very confused, any help would be appreciated.

EDIT: fixed my problem, someone had enabled an ssh daemon in windows already which was conflicting with the WLS one, so I moved it to a different port. They both work now.

[hacnet]

@rodrymbo I've been able to autostart sshd whether user is logged on or not but only by stopping lxssmanager first, i.e. point taskschd to a batch script with the following content:

sc stop lxssmanager c:\Windows\System32\bash.exe -c "/usr/sbin/sshd -D"

but (!) after my subsequent login, I cannot start bash unless I issue the same stop command. It's feels really messy and I'm wondering why this is such a headache? sshd should be up by default It's almost quicker to install Cygwin.

[fpqc]

@hacnet I mean, it's software in development that has only been publicly available for 3 or 4 months (over which time it has advanced in leaps and bounds). I think you have to accept that there will be rough edges for some time into the future.

(For example, you may remember testing Mozilla Firebird back a million years ago, and that took quite a while to reach maturity (before falling off a cliff and murdering the interface (and version numbering system) in recent years), and that project wasn't a quarter as ambitious as this one.)

[hacnet]

@fpqc while I appreciate that dev environments may have some rough edges, you don't start off the project by breaking the fundamental access method to the brand new shell you're announcing.

[fpqc]

@hacnet The fundamental (currently supported) access method is local access through the bash.exe console wrapper (didn't you notice that the whole WSL session dies when you close the last one of these?). Since the console wrapper right now is pretty glitchy and problematic, your next choice is probably something like rxvt (or I think now xterm), which both run with minimal setup through X.

SSH is quite a bit more complicated (it runs as a persistent daemon as root and as a linux "system service"), and offers very little functional improvement over an X terminal emulator. The primary use case in mind with current builds is not really remoting in, and there are better or comparable options when you are on the local machine.

[benhillis]

@hacnet See my https://github.com/Microsoft/BashOnWindows/issues/834#issuecomment-238589089 for a little bit of detail on services. As @fpqc points out this project is in its infancy. It might be helpful for you to think of this GitHub and our User Voice as a way to play a part in the development process. I'll be the first to admit there are many things that need improvement.

[hacnet]

@fpqc @benhillis Not sure why you switched to talking about X. As Windows already has windows, it's not something I missed. Bash however is. Since it should not be presumed that everyone has local access to their Windows 10 machines, I would say accessing the all new bash via sshd cannot be neglected nor put in the "nice to have" box, because many efficient workarounds provide their own Linux emulation thus undermining the whole object of this new subsystem feature.

[fpqc]

@hacnet you can run an X terminal emulator with the Windows port of the Xorg-server project vcXsrv (or Colin Harrison's closed-ish source version Xming, which I hear supports some h/w acceleration stuff that vcXsrv does not yet support). The main point of doing this is to circumvent the currently buggy-to-broken Windows console wrapper for the WSL process /bin/bash called bash.exe. Installing WSL, rxvt, and vcXsrv is still much smaller and faster than installing a full cygwin environment or virtualization.

[aseering]

@fpqc -- if I understand correctly, @hacnet 's use case is accessing a remote Windows machine via ssh. Presumably in order to get remote access to files and state on that machine? (If you're just using WSL as a stateless remote Linux dialup, not to put down the WSL folks, but honestly a Linux machine is going to make a better Linux dialup than a Windows machine :-) )

Windows offers Remote Access as an alternate means of logging into a remote system. But Remote Access is bandwidth-intensive and higher latency. If what you need is a terminal, or you're just copying files around, IMO ssh (or sftp, with a graphical client) is a much more pleasant experience.

[hacnet]

@fpqc Surely I'm not the only one whose WLS incentive and/or expectation is to finally be free of multi-tiered installs. Or at least to reduce them. At work, an Ubuntu environment accessible via ssh could amalgamate a whole range of system administration that otherwise needs to be split up between Windows and Unix/Linux teams. I certainly agree with avoiding virtualization solutions that all but cripple local workstations, yet I've not noticed so many performance issues running Cygwin (on relatively modern hw), so replacing it with a suite of 3 doesn't seem appealing. Thanks for the suggestion though.

[hacnet]

@aseering At home I want the one server for all things. It cannot do without Windows because certain things simply don't get developed for Linux, while at work I would want server administration, historically focused on Unix, universally applied to include Windows nodes. I see WSL as a possible path to these goals.

[fpqc]

@hacnet Sure, but you have to remember that since the initial release into the insider stream, the team has been under instruction from their management to focus mainly on the single-workstation/client single-user use case, not the server/multi-client one. If you notice, WSL installs a completely separate system for each Windows 10 user, further stressing the single-user use case.

However, as a consequence of the software doing the emulation where it does (in the kernel-space, as a (theoretically) co-equal subsystem to Win32 (both kernel subsystems see their syscalls translated into native NT kernel syscalls)), it turns out that it is possible to run a lot of software that was not included in the initially-targeted use case.

Because the team (and their managers probably) have seen such an outpouring of enthusiasm for things like running sshd as a service (and other things like running the rxvt daemon in the background, xsettingsd, unity-settings-daemon, or whatever), they are planning to come up with an elegant way to do it, but it didn't make it into the anniversary update. They chose to release the feature as a beta because there was a lot of interest in it, and they felt like there was enough work ready to go that devs might actually use it (but that they should be aware that it isn't finished yet by any means, which is why it has a big (beta) right after the name when you install it in programs & features).

I guess all I'm saying is try to be a little patient and understand that the reason why your desired feature didn't make it into the anniversary update is that it simply wasn't planned at the start. It seems like it may make it into some of this year's builds though!

[aseering]

It occurs to me that I haven't posted this link here yet:

http://wsl-forum.qztc.io/viewtopic.php?f=6&t=10

Forum post that's intended to summarize how to get sshd working under WSL. Based on the discussion that initially started in this and other threads.

There seem to be a bunch of tickets being filed here about getting ssh working. Would it make sense to consolidate them in the single forum thread, so that everyone sees the same information and those of us who help out with these tickets don't have to repeat things that have already been discovered?

[aseering]

@hacnet -- ah, that use case makes sense. It's not WSL's initial stated use case, as @fpqc has described. But I'm confident that the WSL folks are thinking hard about it.

[hacnet]

@aseering Just saw your reference to: http://wsl-forum.qztc.io/viewtopic.php?f=6&t=10 Another forum to sign up for? set ws=wscript.createobject("wscript.shell") didn't work for me - Event Viewer came up with all kinds of dcom permission issues. The errors disappeared after painstakingly searching for, and taking ownership of, respective AppIDs then adjusting component execution rights. Yet my leaps of joy soon stopped when I saw the server still didn't start while no user was logged on. I'm also unlcear on the script's purpose (sorry no exposure to vbs), since sshd seemed to autostart without logged on users without it - as long as a sc stop lxssmanager command was issued first.

[rodrymbo]

@hacnet - It's not clear to me why creating a wscript.shell object would open Event Viewer. If Event Viewer was supposed to open, someone would have mentioned it, and perhaps remarked that the dcom permission issues are normal for Windows 10, as unlikely as that might seem, and most everyone has them, not just those running WSL. Perhaps one of the Microsoft folks here has a different perspective, but I think I recall someone saying to ignore the errors. Maybe at some point Microsoft plans to fix the problem, so our error logs aren't filled with ridiculous error messages, but that has nothing to do with WSL (that I've seen reported anyway).

As for bash.exe running when no one is logged in: there seems to be some confusion about whether that is actually workable. I saw the sc stop lxssmanager instruction, but haven't had an occasion to test it; for one reason, I thought I saw someone say that the lxssmanager service is configured for "Manual" start (on boot) and that it runs automatically when bash.exe is run, and shuts itself down soon after bash.exe exits. So why one would need to run the sc stop lxssmanager soon after boot but before anyone had invoked bash.exe, makes little sense. I'm not saying that it doesn't work for you, just that it is one more thing that doesn't make sense (to me). Plus it is a bit too much work for me right now to document what happens (or doesn't happen) before someone logs in. (Yes, I could do it. Maybe I'm just lazy.)

As for the vb script file to start bash.exe: the same script file could also run sc.exe first, if the wscript.shell object can be created on your machine and Event Viewer doesn't interrupt. If you want to experiment. But such experimentation amounts to hacking (in the good sense), looking into ways to make things work in ways they weren't supposed to work.

Anyway, github is a place to report "bugs". WSL was designed (for some reason) to make it hard to run scripts in the background, let alone when no one has yet logged in, so those are "features", not bugs. That means that UserVoice is where requests/suggestions/complaints about it need to be lodged. It's also why Adam started the forum. It is not official, just a place for people who want to make WSL do the kind of work we need done. Perhaps your input and suggestions there could help. For example, the "sc" hack has been mentioned as working sometimes, but causing problems other times. It'd be great to know its limitations, interactions, and perhaps a bit more about how it works or how to make it work.

It's clear that services, daemons, and background jobs are still problemmatic, but the Microsoft folks hereabouts say that it is on their list. I suppose that means another strategy is to set aside one's WSL experimentation for a couple of months, then come back and see if the "feature" has been changed so it does what you (we) want or need.

[hacnet]

@rodrymbo just to clarify... it was me (not the script) that opened Event Viewer, trying to find clues in Windows Logs as to why things didn't autostart. I thought I saw a connection between the wscript and the dcom errors which is why I continued to look for solutions without it. Dcom errors might well have been red herrings whereby startup failures were caused not by ownership or launch privileges but because something that bash.exe needed was already running. This theory seemed to be confirmed when observing results after sc stop was included in the batch. I should however add that I've reinstalled lxss a few times. This might also cause varying results depending on how (un)clean it removes itself. I might retry the whole thing on a fresh OS when I have time.

[bunklung]

I just wanted to comment on the work @imjakey had done.

"I use two scripts to achieve my goals:

script 1 named startssh.bat, the contents is :
cd C:\Windows\System32
bash.exe -c "/usr/sbin/sshd -D"

script 2 named autostartssh.vbe, the contents is :
set ws=wscript.createobject("wscript.shell")
ws.run "startssh.bat /start",0

the script 2 can run script 1 like a deamon, then I add scipt 2 to a Windows Task Scheduler, it will run on the computer starts."

I had to edit my /etc/ssh/sshd_config to:

ListenAddress 0.0.0.0
UsePrivilegeSeparation no
PasswordAuthentication yes

Then I had to create a task and make certain it was run with elevated privileges otherwise ping does not work within bash or the SSH session.

Additionally, I had to change the bat file to include a different port (2222 for example): bash.exe -c "sudo /usr/sbin/sshd -D -p 2222"

Why? Because for some reason SSH (CMD.exe NOT WSL/Bash) is enabled on Windows 10 which uses port 22. Perhaps this is because I use Power Shell too? I know this was planned, but I didn't expect for it to be turned on. Surprise!

Additionally I choose not to have the event start automatically. I have no trigger for the event, I just create a shortcut which calls the task when I want SSH/WSL to run in the background. Help found here: http://www.digitalcitizen.life/use-task-scheduler-launch-programs-without-uac-prompts

update I also forgot to mention that I had to add an exception to sudo (sudo visudo) so that a password would not be prompted for running sshd:

username host = (root) NOPASSWD: /usr/sbin/sshd

update 2 I don't use the bat file method now, I just have one script now with this command:

set ws=wscript.createobject("wscript.shell")
ws.run "C:\Windows\System32\bash.exe -c 'sudo /usr/sbin/sshd -D -p 2222'",0

I launch my task with a windows shortcut: C:\Windows\System32\schtasks.exe /run /tn SSHD-2222-WSL OR If I want I want it to silently startup I create a new VBE script which a place in my startup folder:

set ws=wscript.createobject("wscript.shell")
ws.run "C:\Windows\System32\schtasks.exe /run /tn SSHD-2222-WSL",0

This way Task Manager doesn't show the task as constantly running IF I instructed the task to automatically load on startup.

[gdh1995]

Update: bash.exe -c "/usr/sbin/sshd" will cause Connection closed by ....

Since /usr/sbin/sshd needs the root privilege, this command may be helpful:

• sudo chmod +s /usr/sbin/sshd
• Then, I can run /usr/sbin/sshd -D directly from a user gdh1995.
• nohup also works well.

Only one process sshd (along with the init) will be created - sudo is not needed.

The +s mod means sshd will be always ran as root, no matter whatever user you are using.

[rodrymbo]

There's a script for that! sudo /etc/init.d/ssh start. Yes, you might want to add the NOPASSWD: option to the sudo visudo (sudoers) file, and yes it is a few extra characters to type. (Or put into a script file.) As an added bonus, you can do sudo /etc/init.d/ssh stop to gracefully stop the server, and you can issue the start command as often as you want because the script checks to make sure only one instance is running. One would think the people who worked on that script had thought of everything over the 20+ years it has been in development. Or one could invent a new way to start sshd.

Or instead of running sshd suid root, one could just use lxrun.exe /setdefaultuser root and run everything as root. That's how people used to do it in the old days, before they got bit by security problems or fumble-fingers, and, magically, a lot of linux people and distros started using unprivileged users and sudo and avoiding suid.

There's no reason not to experiment with suid on WSL, since no one else can use one's WSL instance (unless one shares one's computer with them). But there are good reasons to stay away from it on regular linux servers.

One can use sudo sshd -D to good effect in some places where sudo /etc/init.d/ssh start doesn't get it exactly right. For example, in a script started by Task Scheduler, bash.exe -c "sudo sshd -D" (or something like that) will happily run almost forever mostly in the background, meaning you don't have to worry about accidentally closing the last bash.exe window and losing all background tasks that you hoped would finish. The same trick can work other ways too, such as a script like

#! /usr/bin/bash
/etc/init.d/ssh start
/usr/sbin/cron -f

which launches sshd in the background, then cron in the foreground (cron's -f does essentially what sshd's -D does), so one has cron holding the Bash.exe window open forever. (There's no corresponding startup script for cron like /etc/init.d/ssh, though you could make one.) Store that in /usr/local/sbin/ and run from sudo. Such a script could be a "temporary replacement upstart (or init)" until WSL figures out whether to support services and daemons and background tasks. (Well, okay, there may be an extra bash process kicking around, but it doesn't eat much and probably needs a home.)

Linux, at least the parts rooted in terminals, thinks of interactive access through terminals. There is a console, but that's rarely the main way people used a shell prompt. Lately there are x-windows servers that can host a terminal emulator, but there are windows native emulators like PuTTY that don't require all that other stuff. But the traditional use of bash scripts is to do stuff in the background, or launch it from cron (a service) or use it to interact with things that run as services, like email and web servers. So launching sshd as a server, and connecting to it via a terminal emulator, makes excellent sense to me.

I still haven't solved the problem of getting sshd or other services going before my user has logged in. But once logged in, the "services" can run constantly until I log out again. Closer to what I want.

[therealkenc]

correction edit: @bunklung's instructions avoid password prompt on starting sshd, not avoiding password when logging into WSL with ssh.

[bunklung]

How is it any more insecure than having RDC on? SSH is still password protected as is PowerShell SSH instance.

[therealkenc]

The difference is RDC depends on windows security service. That sudoers setup means I can scrape your C drive if I have a smart phone in your house and you've given me your WiFi password. [edit - apologies/clarification: I am talking about people lobotomizing sshd with sudoers, not listening on 0.0.0.0 as root, which is of course fine as long as you have your WSL credentials encrypted with public keys.]

[bunklung]

With what password and username? Authentication is on.

[therealkenc]

Maybe I am misunderstanding your set up. Are you prompted when you ssh in or not? If not, then neither will anyone who you have given WiFi access to your network.

sudo visudo
username host = (root) NOPASSWD: /usr/sbin/sshd

[bunklung]

That sudo/visudo change is so that I can launch SSHD without a sudo password prompt. The script that launches SSHD is non-interactive.

[bunklung]

And yes, anyone who SSH's into my setup requires a username and password on both 22 (PowerShell) and 2222 (WSL).