Handle unknown pubkeys

[reynir]

This PR delays parsing of public keys offered by clients. This allows clients to offer keys we don't know how to use to the server, and the server can reject them gracefully.

Things to do

• [x] Check the signature algorithm is compatible with the public key
• [x] According to RFC 4252 the client MAY offer a signature without first probing the key. To implement this we need to further delay more parsing. I don't know how many clients behave this way, and as I've not encountered this behavior before we could defer implementing this to another PR.
• [x] Figure out if we need to check the duplicated occurrences of signature algorithm and key type (the RFCs conflate both as "public key algorithm"). It may be helpful to look at what openssh does.

[reynir]

Relevant reading https://www.rfc-editor.org/rfc/rfc8332#section-2

and in section 3.2:

If the client includes the signature field, the client MUST encode
the same algorithm name in the signature as in
SSH_MSG_USERAUTH_REQUEST -- either "rsa-sha2-256" or "rsa-sha2-512".
If a server receives a mismatching request, it MAY apply arbitrary
authentication penalties, including but not limited to authentication
failure or disconnect.

So it seems a client MUST put matching signature algorithms (known as public key algorithms in the RFCs with all its ambiguity). A server MAY reject it. In openssh they seem, for rsa keys, to generally enforce this with the exception of ssh-rsa-cert-v01 https://github.com/openssh/openssh-portable/blob/2709809fd616a0991dc18e3a58dea10fb383c3f0/ssh-rsa.c#L504-L507

[reynir]

I don't think it would require much change to support clients that don't probe keys first. I can take a look at implementing that later this week. Otherwise I think this PR is ready.

[hannesm]

thanks a lot