Cannot autostart sshd service

[PurplProto]

I'd like for the sshd service to autostart upon opening bash however, it seems to not work.

To attempt this I ran sudo update-rc.d ssh default closed and reopened bash, sudo service ssh status revealed that the service is not running. I attempted to ensure the init script was executable by running sudo chmod 755 /etc/init.d/ssh. But still no luck. I removed ssh from the start script and re-added it again using sudo update-rc.d ssh start 20 2 3 4 5 . stop 20 0 1 6 . and proceeded to restart my machine completely (for good measure), launched bash and the service still isn't running.

I have no trouble manually starting ssh and can successfully connect to it from another device.

Last of all my Windows build number is 14393.187.

[aseering]

Hi @ChrisM-Rogers -- WSL does not "boot" in the traditional sense; upstart scripts are not run automatically.

There are a number of existing tickets discussing different aspects of getting sshd working, including #300 and #612 . If you search this bug tracker for "sshd", you'll find additional related posts.

There's a forum post here about how to get ssh to start using the Windows Task Scheduler.

[fpqc]

Ideally the (futureproof) solution to this would be replacing MS's hardcoded init with some kind of plugin or service hosted by systemd, which would take its place as the init.

We're not there yet on kernel features (systemd uses some parts of cgroups), and init keeps gaining more and more functionality, so I guess we'll see how they do it. Systemd is modular, and systemd's actual init daemon is only about 600 or so lines of code, so maybe MS's team will decide that they'd prefer to do a drop-in replacement for that (basically have MS's linux imit act as the replacement of systemd's "kernel"). Interestingly if they GPL the init process, they could probably maintain it all as a minimal fork of systemd's init.

[therealkenc]

It can't be "hosted by systemd" because WSL is intended to be distribution agnostic. There is nothing to fork off of systemd, because there is no reason to believe systemd exists on the filesystem.

[therealkenc]

There's a glimmer of light in the interoperability blog post. "In the future if we begin running other Ubuntu daemons we will likely switch our daemon from replacing /sbin/init to simply being another daemon on the system."

[gczuczy]

This would be nice to have. Also, please don't do systemd, that's a horrible mess of code.

[fpqc]

@gczuczy In theory if they support systemd they will support any init system. Thing is that all big distros are using systemd as default (ubuntu, debian, arch, centos, fedora, RHEL). Since most Linux users are happy to use the default init system for the foreseeable future, it would be nice to see it supported.

I bet if you wanted to compile a custom gentoo userspace, you could probably get a fully working version of whatever it is they use (OpenRC, or rc.d I think it is called?) by hacking it to let it run as PID!=1)

[therealkenc]

Ironically you are correct. If they support systemd, they will support any init system, by definition -- because the syscall surface of systemd is open-ended and not POSIX. [Well, any init system that doesn't hit even more nonstandard surface than systemd, anyway.]

Ubuntu adopted systemd in April 2013. Any Linux init compiled for amd64 in April 2003, thirteen years ago, will run on WSL today. I am pretty confident that same circa 2003 init will run on WSL in 2029, thirteen years from now. How confident are you that your current /bin/systemd will run in 2029?

Also something else to consider. While Ubuntu, Debian, etc etc have adopted systemd, the vast majority of Linux kernels in the world do not spawn systemd on boot. Because those kernels are running on Android phones, on Chromebooks, and in racks at Amazon, Google, or Microsoft.

Which is not to diminish correctness of your observation that "it would be nice to see it supported".

That said, it would have been equally "nice" if Canonical had not adopted systemd. Because, had they not, I am pretty sure we wouldn't be discussing a github issue with the title "Cannot autostart sshd service". In that alternate universe, Microsoft would not have had to roll their own init to work around the fact that Ubuntu's default process wants to check if you have a USB camera connected before spawning bash or login.

[aseering]

@therealkenc -- you have a point that systemd does more than WSL wants it to do. But lots of issues with titles like the one you're pointing out were filed against Ubuntu 14.04, which does not use systemd. I think the first thing that needs to happen is that WSL's support for headless daemon processes needs to mature a bit. (For starters, how about a supported and pure Linux-side story for daemon processes staying open with no visible console window?) Once that happens, I think discussions about the limits of systemd will become more meaningful.

You could claim that the old upstart system had some related limitations, and I wouldn't disagree. But those are the types of boot systems that people are building today; therefore what WSL has to support. I can't imagine that any modern systemd replacement for desktop Linux would not have some sort of story at least for init-script dependency management, modern hardware/devices (for example, I use a USB dongle for Ethernet; I need a boot system that won't try to bring up network services until it has enumerated USB devices and found the Ethernet chipset), probably at least some story (either direct support or integration with some other system) for security isolation by default given the modern proliferation of things like ransomware, botnets, etc. I'd like to see WSL have better support for the APIs for those things.

[therealkenc]

Dupe of #834, #612, #511 etc.

[rustyx]

@therealkenc those "dupes" will keep on coming until you fix the issue.
And no, adding scripts to shell:startup is NOT a solution.
The corresponding distro (e.g. debian.exe) should start the services according to how they are marked as "autostart" in that particular distro.

[therealkenc]

those "dupes" will keep on coming

I am sure they will. It's a big Internet, there are people who aren't able or willing to search for dupes on their own, and just on a statistical basis (because tens of thousands of WSL users) it is bound to happen. That a small minority of users don't search for dupes before posting is most unfortunate, and drags down the signal to noise ratio and overall usefulness of this github repo, but what can ya do.

until you fix the issue

Me??? Heck I fixed the problem to my own personal satisfaction last year. I don't use the fix mind you (it was a "what would it take" experiment), because ....

adding scripts to shell:startup is NOT a solution.

.... it kinda is. Actually, between you and me, I type sudo service ssh start (because I type very fast).

I don't work for or speak for MSFT, natch. Maybe the devs are working on systemd. Couldn't tell ya (I've never asked). I can, however, tell you this issue was closed by virtue of it being a dupe. The UserVoice is here (200 votes as of this writing) and the unofficial landing zone is #994 these days.

[rescenic]

Use sudo /usr/sbin/sshd