[Bug 1674330] Re: Please consider dropping /etc/network/if-up.d/openssh-server
Launchpad Bug Tracker
1674330 at bugs.launchpad.net
Thu Nov 15 16:29:05 UTC 2018
This bug was fixed in the package openssh - 1:7.9p1-1
---------------
openssh (1:7.9p1-1) unstable; urgency=medium
* New upstream release (https://www.openssh.com/txt/release-7.9):
- ssh(1), sshd(8): allow most port numbers to be specified using service
names from getservbyname(3) (typically /etc/services; closes:
#177406).
- ssh(1): allow the IdentityAgent configuration directive to accept
environment variable names. This supports the use of multiple agent
sockets without needing to use fixed paths.
- sshd(8): support signalling sessions via the SSH protocol. A limited
subset of signals is supported and only for login or command sessions
(i.e. not subsystems) that were not subject to a forced command via
authorized_keys or sshd_config.
- ssh(1): support "ssh -Q sig" to list supported signature options.
Also "ssh -Q help" to show the full set of supported queries.
- ssh(1), sshd(8): add a CASignatureAlgorithms option for the client and
server configs to allow control over which signature formats are
allowed for CAs to sign certificates. For example, this allows
banning CAs that sign certificates using the RSA-SHA1 signature
algorithm.
- sshd(8), ssh-keygen(1): allow key revocation lists (KRLs) to revoke
keys specified by SHA256 hash.
- ssh-keygen(1): allow creation of key revocation lists directly from
base64-encoded SHA256 fingerprints. This supports revoking keys using
only the information contained in sshd(8) authentication log messages.
- ssh(1), ssh-keygen(1): avoid spurious "invalid format" errors when
attempting to load PEM private keys while using an incorrect
passphrase.
- sshd(8): when a channel closed message is received from a client,
close the stderr file descriptor at the same time stdout is closed.
This avoids stuck processes if they were waiting for stderr to close
and were insensitive to stdin/out closing (closes: #844494).
- ssh(1): allow ForwardX11Timeout=0 to disable the untrusted X11
forwarding timeout and support X11 forwarding indefinitely.
Previously the behaviour of ForwardX11Timeout=0 was undefined.
- sshd(8): when compiled with GSSAPI support, cache supported method
OIDs regardless of whether GSSAPI authentication is enabled in the
main section of sshd_config. This avoids sandbox violations if GSSAPI
authentication was later enabled in a Match block.
- sshd(8): do not fail closed when configured with a text key revocation
list that contains a too-short key.
- ssh(1): treat connections with ProxyJump specified the same as ones
with a ProxyCommand set with regards to hostname canonicalisation
(i.e. don't try to canonicalise the hostname unless
CanonicalizeHostname is set to 'always').
- ssh(1): fix regression in OpenSSH 7.8 that could prevent public-key
authentication using certificates hosted in a ssh-agent(1) or against
sshd(8) from OpenSSH <7.8 (LP: #1790963).
- All: support building against the openssl-1.1 API (releases 1.1.0g and
later). The openssl-1.0 API will remain supported at least until
OpenSSL terminates security patch support for that API version
(closes: #828475).
- sshd(8): allow the futex(2) syscall in the Linux seccomp sandbox;
apparently required by some glibc/OpenSSL combinations.
* Remove dh_builddeb override to use xz compression; this has been the
default since dpkg 1.17.0.
* Simplify debian/rules using /usr/share/dpkg/default.mk.
* Remove /etc/network/if-up.d/openssh-server, as it causes more problems
than it solves (thanks, Christian Ehrhardt, Andreas Hasenack, and David
Britton; closes: #789532, LP: #1037738, #1674330, #1718227). Add an
"if-up hook removed" section to README.Debian documenting the corner
case that may need configuration adjustments.
-- Colin Watson <cjwatson at debian.org> Sun, 21 Oct 2018 10:39:24 +0100
** Changed in: openssh (Ubuntu)
Status: In Progress => Fix Released
--
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/1674330
Title:
Please consider dropping /etc/network/if-up.d/openssh-server
Status in openssh package in Ubuntu:
Fix Released
Bug description:
The /etc/network/if-up.d/openssh-server hack was introduced ten years ago [1] as a response to bug
103436. At least from today's perspective this isn't justified:
I can't seem to be able to actually reproduce that issue: I can start
a VM with no network interfaces, remove the above hack, then start
sshd, then bring up an ethernet interface, and I can connect to ssh
via ethernet just fine. Also, e. g. Fedora has no counterpart of this
hack, and these days a lot of people would complain if that would
cause problems, as hotpluggable/roaming network devices are
everywhere.
The hack introduces a race: you run into connection errors after
bringing up a new interface as sshd stops listening briefly while
being reloaded. That's the reason why I looked at it, as this
regularly happens in upstream's cockpit integration tests.
Also, /etc/network/if-up.d/ isn't being run when using
networkd/netplan, i. e. in more recent Ubuntnu cloud instances. So far
this doesn't seem to have caused any issues.
I asked the original reporter of bug 103436 for some details, and to
check whether that hack is still necessary. There is actually a
proposed patch upstream [2] to use IP_FREEBIND, which is the modern
solution to listening to all "future" interfaces as well. But at least
for the majority of cases it seems to work fine without that even.
So I wonder if it's time to bury that hack?
[1] https://anonscm.debian.org/cgit/pkg-ssh/openssh.git/commit/?id=ba6b55ed6
[2] https://bugzilla.mindrot.org/show_bug.cgi?id=2512
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1674330/+subscriptions
More information about the foundations-bugs
mailing list