Public bug reported: [Impact]
* 18.04 LTS release with a long support time frame * There are two versions of OpenSSL shipped in 18.04: - obsolete 1.0.2 - current long term supported 1.1.1 series * OpenSSH in 18.04 is the only package in main using libcrypto from 1.0.2 * The fact that OpenSSH uses a different libcrypto implementation impacts certification, compliance, and security maintenance. * Furthermore OpenSSH does not benefit from hardware accelerated crypto, as available in 1.1.1 * Thus there is a desire to upgrade OpenSSH in 18.04 from 1:7.6p1-4 to 1:7.9p1-10 and compile against OpenSSL 1.1.1 * 1:7.9p1-10 is currently shipped in Disco/Eoan, and it is likely that 20.04 will ship with 1:8.0p1 or newer. Thus security maintainance burden is slightly increased. However, 1:7.9p1-10 is likely to be shipped in the next stable Debian release, and supported there for a long-ish time including debian-lts efforts. Thus there are some synergies. [Upstream Changelogs] * https://www.openssh.com/txt/release-7.9 * https://www.openssh.com/txt/release-7.8 * https://www.openssh.com/txt/release-7.7 [Test Case] * Install openssh-server and openssh-client, check that they depend on libssl1.1 and do not depend on libssl1.0 * Check that there are no new connectivity issues between old/new servers and clients, at the very least between various Ubuntu releases in the public clouds. [Regression Potential] v7.9 * ssh(1), sshd(8): the setting of the new CASignatureAlgorithms option (see below) bans the use of DSA keys as certificate authorities. DSA keys as certificate authorities are widely banned already. May affect connectivity. * sshd(8): the authentication success/failure log message has changed format slightly. It now includes the certificate fingerprint (previously it included only key ID and CA key fingerprint). This may impact log parsers, i.e. logwatch and similar. Possibly worth a NEWS entry. v7.8 * ssh-keygen(1): write OpenSSH format private keys by default instead of using OpenSSL's PEM format. The OpenSSH format, supported in OpenSSH releases since 2014 and described in the PROTOCOL.key file in the source distribution, offers substantially better protection against offline password guessing and supports key comments in private keys. If necessary, it is possible to write old PEM-style keys by adding "-m PEM" to ssh-keygen's arguments when generating or updating a key. Normally, it shouldn't matter which format newly generated keys use. Existing keys remain unchanged. Systems that automatically generate/parse/store keys may be impacted. The risk here is low. As potential mitigation we can revert the default back to PEM for the SRU into bionic. * sshd(8): remove internal support for S/Key multiple factor authentication. S/Key may still be used via PAM or BSD auth. S/Key is not widely deployed. Most common OTP implementations use PAM stack, and use HOTP, TOTP, Yubikey and similar one time passwords, rather than S/Key. This is deemed low. * ssh(1): remove vestigal support for running ssh(1) as setuid. This used to be required for hostbased authentication and the (long gone) rhosts-style authentication, but has not been necessary for a long time. Attempting to execute ssh as a setuid binary, or with uid != effective uid will now yield a fatal error at runtime. This is security and hardening improvement. We do not ship sshd setuid. * sshd(8): the semantics of PubkeyAcceptedKeyTypes and the similar HostbasedAcceptedKeyTypes options have changed. These now specify signature algorithms that are accepted for their respective authentication mechanism, where previously they specified accepted key types. This distinction matters when using the RSA/SHA2 signature algorithms "rsa-sha2-256", "rsa-sha2-512" and their certificate counterparts. Configurations that override these options but omit these algorithm names may cause unexpected authentication failures (no action is required for configurations that accept the default for these options). This is potentially a problem. We can add upgrade hooks to warn users about these, or abort the upgrade. This will require user configuration changes, if they set these settings (which might be done by config management systems). These are not widely used options. May affect connectivity. * sshd(8): the precedence of session environment variables has changed. ~/.ssh/environment and environment="..." options in authorized_keys files can no longer override SSH_* variables set implicitly by sshd. This is security and hardening improvement. Thus desirable to ship. Should not affect connectivity. * ssh(1)/sshd(8): the default IPQoS used by ssh/sshd has changed. They will now use DSCP AF21 for interactive traffic and CS1 for bulk. For a detailed rationale, please see the commit message: https://cvsweb.openbsd.org/src/usr.bin/ssh/readconf.c#rev1.284 This change has been reverted in the -10 distribution packaging. v7.7 * ssh(1)/sshd(8): Drop compatibility support for some very old SSH implementations, including ssh.com <=2.* and OpenSSH <= 3.*. These versions were all released in or before 2001 and predate the final SSH RFCs. The support in question isn't necessary for RFC-compliant SSH implementations. This is security and hardening improvement. Deemed low to affect anyone. ** Affects: openssh (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: openssh (Ubuntu Bionic) Importance: Undecided Status: Confirmed ** Affects: openssh (Ubuntu Cosmic) Importance: Undecided Status: Confirmed ** Affects: openssh (Ubuntu Disco) Importance: Undecided Status: Fix Released ** Affects: openssh (Ubuntu Eoan) Importance: Undecided Status: Fix Released ** Also affects: openssh (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: openssh (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: openssh (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: openssh (Ubuntu Disco) Importance: Undecided Status: New ** Changed in: openssh (Ubuntu Eoan) Status: New => Fix Released ** Changed in: openssh (Ubuntu Disco) Status: New => Fix Released ** Changed in: openssh (Ubuntu Cosmic) Status: New => Confirmed ** Changed in: openssh (Ubuntu Bionic) Status: New => Confirmed -- 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/1832356 Title: Upgrade OpenSSH to 7.9p1-10 or better in stable series Status in openssh package in Ubuntu: Fix Released Status in openssh source package in Bionic: Confirmed Status in openssh source package in Cosmic: Confirmed Status in openssh source package in Disco: Fix Released Status in openssh source package in Eoan: Fix Released Bug description: [Impact] * 18.04 LTS release with a long support time frame * There are two versions of OpenSSL shipped in 18.04: - obsolete 1.0.2 - current long term supported 1.1.1 series * OpenSSH in 18.04 is the only package in main using libcrypto from 1.0.2 * The fact that OpenSSH uses a different libcrypto implementation impacts certification, compliance, and security maintenance. * Furthermore OpenSSH does not benefit from hardware accelerated crypto, as available in 1.1.1 * Thus there is a desire to upgrade OpenSSH in 18.04 from 1:7.6p1-4 to 1:7.9p1-10 and compile against OpenSSL 1.1.1 * 1:7.9p1-10 is currently shipped in Disco/Eoan, and it is likely that 20.04 will ship with 1:8.0p1 or newer. Thus security maintainance burden is slightly increased. However, 1:7.9p1-10 is likely to be shipped in the next stable Debian release, and supported there for a long-ish time including debian-lts efforts. Thus there are some synergies. [Upstream Changelogs] * https://www.openssh.com/txt/release-7.9 * https://www.openssh.com/txt/release-7.8 * https://www.openssh.com/txt/release-7.7 [Test Case] * Install openssh-server and openssh-client, check that they depend on libssl1.1 and do not depend on libssl1.0 * Check that there are no new connectivity issues between old/new servers and clients, at the very least between various Ubuntu releases in the public clouds. [Regression Potential] v7.9 * ssh(1), sshd(8): the setting of the new CASignatureAlgorithms option (see below) bans the use of DSA keys as certificate authorities. DSA keys as certificate authorities are widely banned already. May affect connectivity. * sshd(8): the authentication success/failure log message has changed format slightly. It now includes the certificate fingerprint (previously it included only key ID and CA key fingerprint). This may impact log parsers, i.e. logwatch and similar. Possibly worth a NEWS entry. v7.8 * ssh-keygen(1): write OpenSSH format private keys by default instead of using OpenSSL's PEM format. The OpenSSH format, supported in OpenSSH releases since 2014 and described in the PROTOCOL.key file in the source distribution, offers substantially better protection against offline password guessing and supports key comments in private keys. If necessary, it is possible to write old PEM-style keys by adding "-m PEM" to ssh-keygen's arguments when generating or updating a key. Normally, it shouldn't matter which format newly generated keys use. Existing keys remain unchanged. Systems that automatically generate/parse/store keys may be impacted. The risk here is low. As potential mitigation we can revert the default back to PEM for the SRU into bionic. * sshd(8): remove internal support for S/Key multiple factor authentication. S/Key may still be used via PAM or BSD auth. S/Key is not widely deployed. Most common OTP implementations use PAM stack, and use HOTP, TOTP, Yubikey and similar one time passwords, rather than S/Key. This is deemed low. * ssh(1): remove vestigal support for running ssh(1) as setuid. This used to be required for hostbased authentication and the (long gone) rhosts-style authentication, but has not been necessary for a long time. Attempting to execute ssh as a setuid binary, or with uid != effective uid will now yield a fatal error at runtime. This is security and hardening improvement. We do not ship sshd setuid. * sshd(8): the semantics of PubkeyAcceptedKeyTypes and the similar HostbasedAcceptedKeyTypes options have changed. These now specify signature algorithms that are accepted for their respective authentication mechanism, where previously they specified accepted key types. This distinction matters when using the RSA/SHA2 signature algorithms "rsa-sha2-256", "rsa-sha2-512" and their certificate counterparts. Configurations that override these options but omit these algorithm names may cause unexpected authentication failures (no action is required for configurations that accept the default for these options). This is potentially a problem. We can add upgrade hooks to warn users about these, or abort the upgrade. This will require user configuration changes, if they set these settings (which might be done by config management systems). These are not widely used options. May affect connectivity. * sshd(8): the precedence of session environment variables has changed. ~/.ssh/environment and environment="..." options in authorized_keys files can no longer override SSH_* variables set implicitly by sshd. This is security and hardening improvement. Thus desirable to ship. Should not affect connectivity. * ssh(1)/sshd(8): the default IPQoS used by ssh/sshd has changed. They will now use DSCP AF21 for interactive traffic and CS1 for bulk. For a detailed rationale, please see the commit message: https://cvsweb.openbsd.org/src/usr.bin/ssh/readconf.c#rev1.284 This change has been reverted in the -10 distribution packaging. v7.7 * ssh(1)/sshd(8): Drop compatibility support for some very old SSH implementations, including ssh.com <=2.* and OpenSSH <= 3.*. These versions were all released in or before 2001 and predate the final SSH RFCs. The support in question isn't necessary for RFC-compliant SSH implementations. This is security and hardening improvement. Deemed low to affect anyone. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1832356/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
