Bug#982950: ssh.service starts sshd before network is online: please switch to After=network-online.target instead of just After=network.target
On Wed, Feb 17, 2021 at 11:46:57AM +0100, Thomas Goirand wrote:
> On 2/17/21 10:14 AM, Colin Watson wrote:
> > On Wed, Feb 17, 2021 at 09:36:15AM +0100, Thomas Goirand wrote:
> >> This means that, until FRR is fully up and running, with the BGP session
> >> established, the server IP (10.x.x.x/32 bound to the loopback interface) isn't
> >> set yet on the server, and the ssh daemon cannot bind on the IP (as it's not
> >> there yet).
> >
> > Are you using ListenAddress in sshd_config?
>
> Yes, with the same IP as above, in order to make sure ssh isn't
> listening on a public IP (which would be a security concern for us).
Oh, that's vital information for this bug - using ListenAddress changes
the constraints on sshd startup, somewhat as described in README.Debian.
In that case I think this is at least arguably a case of needing to keep
your configuration in sync, isn't it? You've made a change to
sshd_config, so you need to change other parts of the system to support
that change.
I'd be happy to try to clarify documentation once we work out what
works.
> > See also
> > https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/, which
> > among other things (in general the tone of that page is that a
> > well-written service should not use After=network-online.target) says:
> >
> > "If you write a server: listen on [::], [::1], 0.0.0.0 and 127.0.0.1
> > only. These pseudo-addresses are unconditionally available."
> >
> > That's what sshd does in its default configuration. If it doesn't work,
> > the systemd documentation suggests that something else is not fulfilling
> > its end of a contract somewhere.
>
> Maybe setting-up net.ipv4.ip_nonlocal_bind=1 (in sysctl.conf) would fix
> my issue, no?
That's the system-wide version of IP_FREEBIND. OpenSSH upstream seems
to have decided not to support IP_FREEBIND
(https://bugzilla.mindrot.org/show_bug.cgi?id=2512), but the sysctl
should work if you're OK with it being system-wide.
I'd also recommend at least considering other approaches to implementing
your security policy that avoid the ordering complexities of
ListenAddress, since there are other ways to prevent incoming
connections on public IP addresses. Approaches I can think of include:
* Reject connections to port 22 at the firewall level (perhaps a
firewall on the local host).
* It might be worth experimenting with Match LocalAddress in
sshd_config. I haven't played with that much myself, and it's
poorly-documented, but I *think* that might allow you to reject any
connections that aren't directed to appropriate addresses.
--
Colin Watson (he/him) [cjwatson@debian.org]
Reply to: