openssh bugs - Dec 2015 - [Bug 2512] New: Use IP_FREEBIND if available for sshd listening socket

https://bugzilla.mindrot.org/show_bug.cgi?id=2512

            Bug ID: 2512
           Summary: Use IP_FREEBIND if available for sshd listening socket
           Product: Portable OpenSSH
           Version: 7.1p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Keywords: patch
          Severity: enhancement
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: jjelen at redhat.com

Created attachment 2763
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2763&action=edit
proposed patch

I had the feeling that this issue was discussed here or on mailing
list, but I can't find it anywhere, so opening new bug.

# Background
Systemd starts sshd server quite early during boot sequence, which
means in some setups, address of network interface might not be
available yet. This causes sshd to fail (if there is only one default
ListenAddress option) and start is tired again later, when the address
is ready to use.

# Problem
When there is defined multiple ListenAddress (local and non-local or
yet non-existent) in sshd_config, the initial startup does fail only on
non-local address, but the overall start is successful. This results in
sshd listening only on localhost address which is usually not much
useful.

# Solution
This can be solved by setting listening socket option IP_FREEBIND,
which allows bind to even non-existing or non-local addresses and as
described in [1]. This feature is available in Linux since 2.4

There is still available workaround with system-wide boolean
/proc/sys/net/ipv4/ip_nonlocal_bind, but having this set up fine
grained per-socket seems like more reasonable.

# Downside
Only downside I can think of is that users will not see the
configuration errors, if they mistype IP address in configuration file.
This can be solved by allowing this only based on some other option or
environment variable (not part of attached patch). Patch was tested on
RHEL 7.0.

[1] http://linux.die.net/man/7/ip

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2512

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
Why can't systemd start sshd after the interfaces have been brought up?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

<bugzilla-daemon at bugzilla.mindrot.org> writes:
> https://bugzilla.mindrot.org/show_bug.cgi?id=2512
> --- Comment #1 from Damien Miller <djm at mindrot.org> ---
> Why can't systemd start sshd after the interfaces have been brought up?
It is entirely possible for systemd to start sshd aftre the interfaces
have been brought up or have it work in an inetd kind of way for each
connection to port 22.

Generally, one uses After=network.target or After=network-online.target
and one may want a Wants=network-online.target or wait for the
sshd-keygen.service to start first.

An example might be:

$ cat sshd.service
[Unit]
Description=OpenSSH server daemon
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target sshd-keygen.service
Wants=sshd-keygen.service

[Service]
EnvironmentFile=/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s

[Install]
WantedBy=multi-user.target
$ 

The use of sshd.socket also allows for inetd like functionality
with systemd if that is what is needed.

	Good luck,
	-- Mark

https://bugzilla.mindrot.org/show_bug.cgi?id=2512

--- Comment #2 from Jakub Jelen <jjelen at redhat.com> ---
The thing is that systemd provides network-online.target [1] and
network.target [2], but the specification what does it mean is quite
vague and it does not tell (for example) which network interface is
ready on systems with more network interfaces.

So far you can take this more like an idea to discuss and track, than
intention to apply the patch in this form. We are still investigating
this behaviour and currently I incline more to have this as config
option or environment variable, rather than turning it on everywhere.

[1]
http://www.freedesktop.org/software/systemd/man/systemd.special.html#network-online.target
[2]
http://www.freedesktop.org/software/systemd/man/systemd.special.html#network.target
[3] http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2512

--- Comment #3 from Jakub Jelen <jjelen at redhat.com> ---
(In reply to Damien Miller from comment #1)
> Why can't systemd start sshd after the interfaces have been brought
> up?
It is the default behaviour to depend on network.target, which waits
before interface is up. But bringing device up is not bringing device
online and setting the correct IP, especially when there is DHCP (if I
understand it well). This works fine on fast DHCP or static setups.

You can set the dependency on network-online.target, but it brings
other dependencies in the boot sequence and slows down the boot.

Having the possibility to use IP_FREEBIND as a configuration option
(ListenAddressFreeBind or some prefix (-) in front of address itself?)
would give us fast boot itself and possibility to tune the network
addresses behaviour if needed.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2512

--- Comment #4 from Damien Miller <djm at mindrot.org> ---
(In reply to Jakub Jelen from comment #3)
> You can set the dependency on network-online.target, but it brings
> other dependencies in the boot sequence and slows down the boot.
Doesn't this only affect users who change ListenAddress from the
wildcard default? If so, can't they simply choose between
wildcard+early or bound+depends-on-network-online?

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2512

--- Comment #5 from Jakub Jelen <jjelen at redhat.com> ---
(In reply to Damien Miller from comment #4)
> (In reply to Jakub Jelen from comment #3)
> 
> > You can set the dependency on network-online.target, but it brings
> > other dependencies in the boot sequence and slows down the boot.
> 
> Doesn't this only affect users who change ListenAddress from the
> wildcard default? If so, can't they simply choose between
> wildcard+early or bound+depends-on-network-online?
Yes, you are right. Default wildcard works fine.

On machines with more network interfaces you are more liable to start
fiddling with ListenAddress.
Using IP_FREEBIND sounds like a reasonable alternative to the second
one.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2512

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
             Status|NEW                         |RESOLVED

--- Comment #6 from Damien Miller <djm at mindrot.org> ---
I don't think we want this ahead of any other systems supporting it.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2512

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #7 from Damien Miller <djm at mindrot.org> ---
closing resolved bugs as of 8.6p1 release

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.