Bug 709580 – net-misc/openssh-8.2 version bump

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Agostino Sarubbo 2020-02-14 08:01:16 UTC]

From https://www.openwall.com/lists/oss-security/2020/02/14/1 :

OpenSSH 8.2 has just been released. It will be available from the
mirrors listed at http://www.openssh.com/ shortly.

OpenSSH is a 100% complete SSH protocol 2.0 implementation and
includes sftp client and server support.

Once again, we would like to thank the OpenSSH community for their
continued support of the project, especially those who contributed
code or patches, reported bugs, tested snapshots or donated to the
project. More information on donations may be found at:
http://www.openssh.com/donations.html

Future deprecation notice
=========================

It is now possible[1] to perform chosen-prefix attacks against the
SHA-1 algorithm for less than USD$50K. For this reason, we will be
disabling the "ssh-rsa" public key signature algorithm by default in a
near-future release.

This algorithm is unfortunately still used widely despite the
existence of better alternatives, being the only remaining public key
signature algorithm specified by the original SSH RFCs.

The better alternatives include:

 * The RFC8332 RSA SHA-2 signature algorithms rsa-sha2-256/512. These
   algorithms have the advantage of using the same key type as
   "ssh-rsa" but use the safe SHA-2 hash algorithms. These have been
   supported since OpenSSH 7.2 and are already used by default if the
   client and server support them.

 * The ssh-ed25519 signature algorithm. It has been supported in
   OpenSSH since release 6.5.

 * The RFC5656 ECDSA algorithms: ecdsa-sha2-nistp256/384/521. These
   have been supported by OpenSSH since release 5.7.

To check whether a server is using the weak ssh-rsa public key
algorithm, for host authentication, try to connect to it after
removing the ssh-rsa algorithm from ssh(1)'s allowed list:

    ssh -oHostKeyAlgorithms=-ssh-rsa user@...t

If the host key verification fails and no other supported host key
types are available, the server software on that host should be
upgraded.

A future release of OpenSSH will enable UpdateHostKeys by default
to allow the client to automatically migrate to better algorithms.
Users may consider enabling this option manually.

[1] "SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and
    Application to the PGP Web of Trust" Leurent, G and Peyrin, T
    (2020) https://eprint.iacr.org/2020/014.pdf

Security
========

 * ssh(1), sshd(8), ssh-keygen(1): this release removes the "ssh-rsa"
   (RSA/SHA1) algorithm from those accepted for certificate signatures
   (i.e. the client and server CASignatureAlgorithms option) and will
   use the rsa-sha2-512 signature algorithm by default when the
   ssh-keygen(1) CA signs new certificates.

   Certificates are at special risk to the aforementioned SHA1
   collision vulnerability as an attacker has effectively unlimited
   time in which to craft a collision that yields them a valid
   certificate, far more than the relatively brief LoginGraceTime
   window that they have to forge a host key signature.

   The OpenSSH certificate format includes a CA-specified (typically
   random) nonce value near the start of the certificate that should
   make exploitation of chosen-prefix collisions in this context
   challenging, as the attacker does not have full control over the
   prefix that actually gets signed. Nonetheless, SHA1 is now a
   demonstrably broken algorithm and futher improvements in attacks
   are highly likely.

   OpenSSH releases prior to 7.2 do not support the newer RSA/SHA2
   algorithms and will refuse to accept certificates signed by an
   OpenSSH 8.2+ CA using RSA keys unless the unsafe algorithm is
   explicitly selected during signing ("ssh-keygen -t ssh-rsa").
   Older clients/servers may use another CA key type such as
   ssh-ed25519 (supported since OpenSSH 6.5) or one of the
   ecdsa-sha2-nistp256/384/521 types (supported since OpenSSH 5.7)
   instead if they cannot be upgraded.

@maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.

[Comment 1 Thomas Deutschmann (RETIRED) 2020-02-14 13:00:43 UTC]

Not a security release. I.e. current versions in Gentoo repository aren't vulnerable.

[Comment 2 vltg0903 2020-02-15 21:29:25 UTC]

Created attachment 613958 [details]
libcbor-0.5.0 ebuild, libfido2 dependency

[Comment 3 vltg0903 2020-02-15 21:31:59 UTC]

Created attachment 613960 [details]
libfido2-1.3.0 by YUBICO, needed for openssh-8.2 FIDO2 support

Hi all,

those two ebuilds are needed for the new FIDO2 usb security key support in openssh, would be cool to see that at some point down the line!

Cheers,
AE

[Comment 4 Kobboi 2020-02-16 00:26:40 UTC]

I have lost the ability to login after this version bump.

Luckily I still have an open session, which shows me

sshd[4020250]: recv_rexec_state: buffer error: incomplete message

[Comment 5 Kobboi 2020-02-16 00:31:58 UTC]

I have logged https://bugs.gentoo.org/709748 to track the above problem

[Comment 6 Thomas Deutschmann (RETIRED) 2020-02-26 22:32:37 UTC]

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=66fb7fe3cdb232fe068325200367653e0ebb964f