Bug 3157

Summary:

known_hosts @cert-authority with legacy plain key entry drops incorrect set of HostKeyAlgorithms

Product:

Portable OpenSSH

Reporter:

Paul Kapp <paullkapp>

Component:

ssh

Assignee:

Damien Miller <djm>

Status:

CLOSED FIXED

Severity:

normal

CC:

djm, dtucker

Priority:

Version:

8.1p1

Hardware:

All

OS:

Mac OS X

Bug Depends on:

Bug Blocks:

3162

Attachments:

Description	Flags
Consider CA keys when automatically determining host key order	none
Prefer certificate algorithm if @cert-authority line appears in hostkeys	none

Description Paul Kapp 2020-05-04 06:50:04 AEST

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@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@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.

Comment 1 Damien Miller 2020-05-04 11:13:57 AEST

Created attachment 3389 [details]
Consider CA keys when automatically determining host key order

Nice catch. Could you please try this patch?

Comment 2 Paul Kapp 2020-05-06 00:43:27 AEST

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.

Comment 3 Paul Kapp 2020-05-06 04:43:08 AEST

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@openssh.com.

The remote host may have a certificate of type ecdsa-sha2-nistp256-cert-v01@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@openssh.com in its priority list.

Comment 4 Damien Miller 2020-05-06 15:02:58 AEST

Created attachment 3390 [details]
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.

Comment 5 Paul Kapp 2020-05-07 18:56:16 AEST

Looks good to me. Thanks for the quick action on this.

Comment 6 Damien Miller 2020-05-13 19:53:12 AEST

This has been committed and will be in openssh-8.4. Thanks!

Comment 7 Darren Tucker 2020-10-02 14:55:04 AEST

Mass close of all bugs fixed in 8.4 release.