[Bug 216847] Re: sshd will not start at boot if ListenAddress is set, because network interface is not yet up
nimish
216847 at bugs.launchpad.net
Fri Jan 24 19:59:23 UTC 2020
Came across this issue on a system I'm rebuilding and spun up a VM
running 18.04.3 to test. It seems like I got it working consistently on
every reboot. I'll try and breakdown what I've tried and what worked.
Everyone & Dev's can let me know if they see any issues of setting it up
the way it's working.
First made a backup of the file /etc/systemd/system/sshd.service just in
case even though you could use systemctl revert ssh.service to revert
any changes.
What I've tried:
editing /etc/systemd/system/sshd.service and changing the following
lines from:
After=network.target auditd.service
to:
After=network-online.target
Wants=network-online.target
or to:
Requires=network-online.target
After=network-online.target
Wants=network-online.target
or to:
Requires=network-online.target auditd.service
After=network-online.target auditd.service
Wants=network-online.target auditd.service
or to:
Requires=whoopsie.service
After=whoopsie.service
Wants=whoopsie.service
What I was trying to see is which service I could have ssh start after
seeing as using the various network.service/targets were just not
working or consistent. Using whoopsie.service worked the first time I
rebooted but each reboot after that ssh failed to start.
I tried the following as well:
systemctl edit ssh.service and putting the above variations in that file
and the ssh.service still failed to start.
When looking at:
systemctl show ssh or systemctl show ssh |grep -C 10 "After" to get the
data I wanted to see.
I see the following "Before=" argument which has multi-user.target
included. When you look at what's in /etc/systemd/system/multi-
user.target.wants/ it includes links to ssh.service, networkd-
dispatcher.service, networking.service & NetworkManager.service.
Names=ssh.service
Requires=sysinit.target system.slice -.mount
WantedBy=multi-user.target
Conflicts=shutdown.target
Before=shutdown.target multi-user.target
After=system.slice systemd-journald.socket network.target sysinit.target -.mount auditd.service basic.target
>From the above data it looks like ssh.service is set to start before
multi-user.target?
So I set out to change that behavior:
I tried putting the following in systemctl edit ssh.service which did
not work
Requires=multi-user.target
Before=shutdown.target
After=multi-user.target
Wants=multi-user.target
Did systemctl revert ssh.service to revert to the original configs
Then I tried systemctl edit --full ssh.service and put
Requires=multi-user.target
Before=shutdown.target
After=multi-user.target
Wants=multi-user.target
reloaded the daemons systemctl daemon-reload. I don't think it totally
necessary to do this if you're going to reboot anyway but why not, no
harm.
Rebooted multiple times and now ssh starts on every reboot/boot.
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/216847
Title:
sshd will not start at boot if ListenAddress is set, because network
interface is not yet up
Status in portable OpenSSH:
Unknown
Status in openssh package in Ubuntu:
Confirmed
Bug description:
Binary package hint: openssh-server
The sshd will not start at boot if the ListenAddress option in
/etc/ssh/sshd_config is set to an IPv4 address other then 0.0.0.0 .
I am using Ubuntu 7.10 and the version 1:4.6p1-5ubuntu0.2 of the openssh-server package.
I would expect that sshd is started after boot but it will not and I found this in /var/log/auth.log:
sshd[4527]: error: Bind to port 22 on 10.1.1.22 failed: Cannot assign requested address.
sshd[4527]: fatal: Cannot bind any address.
Once the System is started you can start/stop the sshd with the
/etc/init.d/ssh script without any problems.
To manage notifications about this bug go to:
https://bugs.launchpad.net/openssh/+bug/216847/+subscriptions
More information about the foundations-bugs
mailing list