Unable to connect with openssh 7.8 client and certificates

Status changed to 'Confirmed' because the bug affects multiple users.

Updated the description - specifically, this appears to affect certificate authentication and be related to <email address hidden> and <email address hidden> which are present in 7.8 server, but not earlier versions (nor are valid to add to the configuration manually).

Thanks Scott for the report, we don't have 7.8 yet (Cosmic will be released with 7.7).
But as I read the issue this already is an issue for all older SSH servers as soon as somebodies client is new.

@cjwatson - you are usually watching over openssh, did you see this already. How should we proceeed in your opinion.

Hi all,

This only affect RSA certificates, not ECDSA or ED25519 certs
Even if your CA is an RSA key, you can sign ECDSA or ED25519 public keys so you get ECDSA/ED25519 certificates which allow you to work around the issue without changing anything server-side
(and without deploying a new CA)

Exemple of working cert (7.8 client, <7.8 server):
$ ssh-keygen -Lf ~/.ssh/id_ed25519-cert.pub
~/.ssh/id_ed25519-cert.pub:
        Type: <email address hidden> user certificate
        Public key: ED25519-CERT SHA256:<...>
        Signing CA: RSA SHA256:<...>
        Key ID: "..."

This [1] appears to be the source of the problem, specifically "Add new RSA certificate types that that can be used in the above options and on the wire to require the use of RSA/SHA2 signatures." - unfortunately, those new certificate types don't exist/work in openssh <7.8, breaking backwards compatibility with 7.8 clients.

Christian - Correct, it doesn't matter that no Ubuntu version is shipping with openssh 7.8 today. Bleeding edge distributions are, and non-Linux users are getting updates to 7.8, which breaks connectivity to any openssh server <7.8 under these circumstances when the client is 7.8.

Etienne - Thank you for providing that - it is the current workaround aside from downgrading clients to 7.7. This is not a complete solution though, as it doesn't help for environments that sign RSA user certificates through an automated service (unless that service supports EC certs, which I'm going to guess may not work with really old versions of openssh).

[1] http://bugzilla.mindrot.org/show_bug.cgi?id=2799

Am I right in understanding that there is no proposed action for Ubuntu to take on this right now?

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 AP...