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 <[email protected]> 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 Touch seeded packages, 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
