Open drakkan opened 1 month ago
Related Issues and Documentation
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)
I suggest a slightly different semantic: the HostKeyCallback
error (let's call it UnknownKeyError
) would be returned for any unknown key, and have a field KnownTypes []string
.
The caller then filters the algorithms to only the ones compatible with those key types. (Host key callbacks don't usually know anything about algorithms, so let's make the error also only concern itself with key types. This also avoids the mistake of returning [ssh-rsa]
and accidentally disabling SHA-2.)
Our client will call the callback proactively with a fake key to filter the ClientConfig.HostKeyAlgorithms
(or the default). Our FixedHostKey
will return the error. knownhosts.KeyError
will add a As
method filling out a UnknownKeyError
.
@FiloSottile thank you. Here is the updated proposal
// UnknownKeyError can be returned from [HostKeyCallback] implementations when
// they receive an unknow key to inform about supported key formats. Our
// [Client] will execute the callback, before connecting, with a non-existent
// key type to discover and use the supported key formats.
type UnknownKeyError struct {
// KnownTypes lists the public key formats that the callback will accept.
KnownTypes []string
}
This also avoids the mistake of returning
[ssh-rsa]
and accidentally disabling SHA-2.)
Just ran into this particular mistake myself with some code that was written prior to the SHA-2 support, so something which encourages this to work would be desirable. I was thinking that maybe in addition to ClientConfig.HostKeyAlgorithms
, there could be a ClientConfig.HostKeyTypes
. But any approach that doesn't require the user of the ssh library to know about different algorithms for the same key type would be great.
Proposal Details
If
ClientConfig.HostKeyAlgorithms
is not set, a reasonable default is set for acceptable host key type, which may be one for which you do not have a matching host key provided usingClientConfig.HostKeyCallback
.If our users don't set
ClientConfig.HostKeyAlgorithms
we should try to obtain the expected algorithms from the configuredClientConfig.HostKeyCallback
.To enable this automatic detection, I propose to add a new error that
HostKeyCallback
implementations can return to inform about supported algorithms:It is preferable to return
HostKeyAlgorithms
and not the key formats because this way implementations can decide, for example, to return only the sha-2 variants for thessh-rsa
key format.if
ClientConfig.HostKeyAlgorithms
is not set, our client will execute the callback passing a sentinel, non-existent, key type and, if the error returned is anHostKeyCallbackError
, the returned host key algorithms are used.We should return
HostKeyCallbackError
in our internalHostKeyCallback
implementations: