3

I have a Fedora 33 under Windows Subsystem for Linux 2.

I want to run sshd. For that I tried

$ sudo systemctl start sshd

but I got the error message

System has not been booted with systemd as init system (PID 1). Can't operate

Searching for this error message I have found

https://linuxhandbook.com/system-has-not-been-booted-with-systemd/

which suggested to use the service command in this case. I tried but it said

Redirecting to /bin/systemctl start sshd.service

so I got the same error.

What can I do on my WSL2 based Fedora 33?

UPDATE: I have installed Fedora onto WSL using a cloud image and the wsl command, described here:

https://fedoramagazine.org/wsl-fedora-33/

3 Answers 3

2

I use fedora 35, but this probably works with other fedora versions too.
Like NotTheDr01ds said , fedora doesn't support service start sshd. So you can run sshd manually by the command nohup /usr/sbin/sshd -D > sshd.log 2>&1 &. Or you will need to make systemd work for wsl.
Since genie supports fedora, so you can try to use it to make systemd work.
Here is the project url: https://github.com/arkane-systems/genie

  1. you can download the rpm package, from this page: https://github.com/arkane-systems/genie/releases

  2. install the genie-*.x86_64.rpm with the command dnf install

  3. use genie with the command genie -s

  4. use systemctl to start sshd systemctl start sshd

You may meet the error Transport endpoint is not connected on the fourth step. This is caused by a known issue of wsl ldconfig.

Follow these instructions to fix it:
https://github.com/microsoft/WSL/issues/5548#issuecomment-990521993
https://github.com/microsoft/WSL/issues/5548#issuecomment-912495487

2

You didn't mention how you installed it, but I assume something like the instructions here. I've never done much with Fedora, so I decided to load up a quick chroot instance of it with Fedora-Container-Base using a combination of the instructions above along with some chroot specific info.

It appears to me that Fedora is "all-in" on systemd, perhaps more so than most other distributions I've seen. For instance, Ubuntu will still let you use the service command, but as you saw Fedora redirects it to systemd anyway. There's not even a init script for ssh to be found under Fedora - It's all systemd service files.

This blog post seems to back that up, using Fedora as an example. It has a number of good suggestions for most other services:

  • Look at the Dockerfiles for services that you want to run to see how they start and stop the service
  • Just use Docker or podman containers anyway.

While good suggestions, they aren't quite as useful for sshd in my opinion.

So I'll add my own suggestion -- Look at systemd files to see the steps they take to configure and launch (and stop/restart) a service.

For sshd under Fedora, the systemd service (usr/lib/systemd/system/sshd.service) has dependencies which detect whether or not the host keys have been generated, and do so if they aren't present (e.g. immediately after install). (I think -- I can't claim to be a guru at reading systemd services.)

So you'll need to do that step manually for starters (if you haven't already):

/usr/libexec/openssh/sshd-keygen ecdsa
/usr/libexec/openssh/sshd-keygen rsa
/usr/libexec/openssh/sshd-keygen ed25519

Personal recommendation/bonus tip -- Change the sshd port to something besides 22. Install Windows OpenSSH Server on the Windows host, which will allow you to easily proxy to any WSL instance on the host.

Then, just start the service manually, using the same command that systemd uses (see the aforementioned .service file):

/usr/sbin/sshd

This works for me in the chroot Fedora 33 environment.

You may want to consider supervisord to manage services in lieu of systemd or another PID 1 init. I've used it under Docker containers, and it worked well for starting/stopping/restarting simple services. You'll have to roll your own config, but it's straightforward. And ultimately, it's nice to have that added manageability and recovery if a service stops unexpectedly.

One more note, since you are working with sshd under WSL -- Keep in mind that WSL2 instances are always pseudo-NAT'd in a virtual NIC behind the Windows host. This means that ssh (or accessing any service under WSL2) from another computer on the network will require additional effort - See my answers here and here on that topic.

0

have a look here:

https://gist.github.com/djfdyuruiry/6720faa3f9fc59bfdf6284ee1f41f950

Greetings kh

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.