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.
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
So you'll need to do that step manually for starters (if you haven't already):
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
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.