openssh bugs - May 2020 - [Bug 3157] New: known_hosts @cert-authority with legacy plain key entry drops incorrect set of HostKeyAlgorithms

https://bugzilla.mindrot.org/show_bug.cgi?id=3157

            Bug ID: 3157
           Summary: known_hosts @cert-authority with legacy plain key
                    entry drops incorrect set of HostKeyAlgorithms
           Product: Portable OpenSSH
           Version: 8.1p1
          Hardware: All
                OS: Mac OS X
            Status: NEW
          Severity: normal
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: paullkapp at gmail.com

Adding a @cert-authority entry into authorized_keys in conjunction with
a "plain" key entry results in the client requesting only host
certificates of the type of the plain key, not the comprehensive list
of certificate types.

Use case: A legacy RSA host key entry in known_hosts, and adding a
@cert-authority entry for a new ed25519 CA. Because the CA can sign
**any** key type, the client should include all certificate types in
the protocol exchange request.

What winds up happening: the plain RSA entry causes the client to only
request keys (and certificates) of the type RSA (and derivatives):
debug3: order_hostkeyalgs: prefer hostkeyalgs:
rsa-sha2-512-cert-v01 at openssh.com,rsa-sha2-256-cert-v01 at
openssh.com,ssh-rsa-cert-v01 at openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa

When the RSA key is removed from the remote host, the hostkey
verification fails, even though a valid (non-RSA) host certificate
could have been sent to the client.

Expected behavior: If the client has a @cert-authority entry in
known_hosts, all certificates types should be requested from the
server.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3157

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |djm at mindrot.org
           Assignee|unassigned-bugs at mindrot.org |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
Created attachment 3389
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3389&action=edit
Consider CA keys when automatically determining host key order

Nice catch. Could you please try this patch?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3157

--- Comment #2 from Paul Kapp <paullkapp at gmail.com> ---
It is different, but not quite correct either, IMO. The CA key type
listed as the @cert-authority entry could be used to sign any key type.

If a @cert-authority is applicable from known_hosts, the client should
include all the available certificate types in the list offered to the
server, since the client is prepared to trust any of the certificate
types SignedBy the CA, and has no way to predict which type(s) may be
available on the server.

Ordering of the list is probably suitable, moving some certificate
types to the head of the list, based on other plain key types matched
in known_hosts, as the fallback to plain keys logic may still be used.
However, the full list (as appears in HostKeyAlgorithms) ought to be
represented.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3157

--- Comment #3 from Paul Kapp <paullkapp at gmail.com> ---
Yes, this patch does happen to fix the particular case, but not the
general case. From my example, my test server had an ed25519 host key
signed by an ed25519 CA, and the client did include a request for host
key/cert of type ssh-ed25519-cert-v01 at openssh.com.

The remote host may have a certificate of type
ecdsa-sha2-nistp256-cert-v01 at openssh.com signed by that same ed25519
CA, which would also be acceptable. If the remote host had only that
cert available, the host validation would fail, since the client does
not include ecdsa-sha2-nistp256-cert-v01 at openssh.com in its priority
list.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3157

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #3389|0                           |1
        is obsolete|                            |
   Attachment #3390|                            |ok?
              Flags|                            |

--- Comment #4 from Damien Miller <djm at mindrot.org> ---
Created attachment 3390
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3390&action=edit
Prefer certificate algorithm if @cert-authority line appears in
hostkeys

yeah, I realised my mistake yesterday too.

Please try this one: it prefers all default certificate algorithms if
the hostkeys files contain a @cert-authority line.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3157

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at dtucker.net
   Attachment #3390|ok?                         |ok?(dtucker at dtucker.net)
              Flags|                            |

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3157

--- Comment #5 from Paul Kapp <paullkapp at gmail.com> ---
Looks good to me. Thanks for the quick action on this.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3157

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |3162


Referenced Bugs:

https://bugzilla.mindrot.org/show_bug.cgi?id=3162
[Bug 3162] Tracking bug for 8.4 release
-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3157

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #6 from Damien Miller <djm at mindrot.org> ---
This has been committed and will be in openssh-8.4. Thanks!

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3157

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #7 from Darren Tucker <dtucker at dtucker.net> ---
Mass close of all bugs fixed in 8.4 release.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3157

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #3390|ok?(dtucker at dtucker.net)    |
              Flags|                            |

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.