Arch Linux

Our service file cannot be expected to work in all scenarios. If you enable a ListenAddress-type option in sshd_config, you are expected to make the relevant changes to the service file as well.

But although I disagree with your argument, I think adding After=network.target might make sense. I am however wary of unexpected consequences (What about people with multiple interfaces wishing to use one (say, the loopback address) before another is set up? Etc.), so I have only added that change to SVN for now and we will see how it goes when openssh goes to [testing] again for its next rebuild.

Actually, no, I do not like adding After=network.target.

The reason is that I (and probably most people) want my SSH daemon to always be running; conditioning this on other things (such as the status of interfaces) seems to just be a source of problems. With the default settings, sshd gets started as early as possible and binds 0.0.0.0:22, therefore is available on every interface regardless of when network.target completes or when that specific interface becomes available. This is I believe the behavior most people expect from their SSH daemon.

So, why httpd.service has After=network.target. It's with default configuration also binds 0.0.0.0

Good question; why don't you take it with the maintainer of whatever package provides httpd.service? Anyhow, an HTTP daemon is not nearly as critical as an SSH one.

if you are worried about sshd.service starting before network.target is set, you should use the sshd.socket instead, it will start one instance of sshd@.service every time something tries to connect. So on boot before network.target is loaded, there is no way for anything to ssh in and trigger the socket, so sshd won't be loaded until someone can ssh in

But sshd.socket still needs an address to bind to as is. You can use the Freebind= option in the socket file to get around this.

This issue happened to me too. FWIW, Fedora 17 has 'After=network.target' in their sshd.service file.

Anyway, I added a warning and instructions in the Arch Wiki https://wiki.archlinux.org/index.php/Ssh#Enabling_the_sshd_daemon_under_a_native_systemd_system.

Thanks for your contribution to the wiki, Sam.

Sorry I sent in that other bug. I did search for it, but this one had already been closed, and this project system doesn't search closed bugs for some reason.

I don't think you're quite understanding how systemd works in this case and why we actually need After=network.target in the unit file. I think you're maybe confusing this with Wants=network.target instead. SSHD by default will bind to 0.0.0.0 regardless, so putting After=network.target in the unit file is simply insurance against someone customizing their SSH configuration and won't affect the default case.

SSHD is a network-based service, so it doesn't make sense to say that you would want the service to start regardless of the state of any network interfaces. The fact that you can do it is meaningless - if you don't have a network up, then sshd is useless anyway. So, starting sshd without network up is very much *not* the expected behavior, which is why other distros configure their unit files the way they do, and (I am sure) is also why the maintainer of the Apache package does as well.

Also, suggesting that we use sshd.socket is not viable because that's not what it's meant for. For instance, if you want to use Mosh you can't use sshd.socket at all and must use the full service configuration. Not including the correct configuration in the service file may suit you just fine, but it forces everyone else who has a decently customized SSH setup to edit the service file and then maintain it, since it gets replaced on every upgrade of sshd.

This is all very well except you are not bringing any new arguments to the table: there is no need to add After=network.target to the SSHD service file, so like anything needless it will not be added to our default file. The only exception is if you customize your sshd_config to bind to specific interfaces and, if you do that, modifying other configuration files accordingly becomes your sole responsibility.

I'm echoing Ryan's comment above; it makes sense to add After=network.target to sshd.service.

As far as I can see, this was implemented in /trunk at some point but reverted because it was
thought to make network.target a dependency of sshd.service. As Ryan explained, this is not
the case and there is no downside to this addition.

In closing, ListenAddress is a perfectly valid option for someone to have in their sshd_config,
and there is no reason not to support it in the shipped sshd.service file.