Arch Linux

Description:

The result being the following:
Mar 04 11:26:05 tau sshd[442]: error: Bind to port 2243 on 10.230.131.4 failed: Cannot assign requested address.
Mar 04 11:26:05 tau systemd[1]: sshd.service: Main process exited, code=exited, status=255/EXCEPTION
Mar 04 11:26:05 tau sshd[442]: fatal: Cannot bind any address.
Mar 04 11:26:05 tau systemd[1]: sshd.service: Failed with result 'exit-code'.

It attempts to bind to an ip address before it is actually configured and available.

There is an easy fix for that. It is to use the systemd target network-online.target instead of the target network.target.

Details are provided here:
https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/

I did fix your service unit file very easily by changing it to:

[Unit]
Description=OpenSSH Daemon
Wants=sshdgenkeys.service network-online.target
After=sshdgenkeys.service network-online.target

[Service]
ExecStart=/usr/bin/sshd -D
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=always

[Install]
WantedBy=multi-user.target

As a side note, I believe that I have stumbled into that bug because I specify a specific ip address of my multi-homed server in sshd_config at the field ListenAddress.

as denoted at the bottom of https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/

servers using the address 0.0.0.0 are unaffected.

Perhaps that an elegant solution to not affect the boot time of systems that don't have this issue could be to bundle 2 service units with openssh.

1. The current one that wants network.target
2. A new unit that wants network-online.target for the sshd instances that listen to specific addresses only available when the network is online.

Here is one last idea. Considering how vital sshd is to admin a remote system, I think that it could be a good idea to never give up attempting to restart it...
This could be done with this:

[Service]
ExecStart=/usr/bin/sshd -D
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=always
StartLimitIntervalSec=0
RestartSec=20s

Additional info:
openssh 8.5p1

Steps to reproduce:

I have a 802.3ad bonding virtual device with a 2 links aggregation. This seems to be a complex enough setup so that if you trie to listen to this virtual device statically assigned IP that isn't 0.0.0.0, you will get the problem.