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.
Created attachment 3389 [details] Consider CA keys when automatically determining host key order Nice catch. Could you please try this patch?
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.
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.
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.
Looks good to me. Thanks for the quick action on this.
This has been committed and will be in openssh-8.4. Thanks!
Mass close of all bugs fixed in 8.4 release.