[Bug 1832356] Re: Upgrade OpenSSH to 7.9p1-10 or better in stable series

[Marc Deslauriers]

** Changed in: openssh (Ubuntu Cosmic)
       Status: Confirmed => Won't Fix

-- 
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/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:
  Won't Fix
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