A useful feature to have for ssh would be KnownHostsCommand, by analogy with KnownHostsFile and ProxyCommand. One possible implementation: if set, KnownHostsCommand would be invoked as a subprocess immediately after receipt of the host's key, with the host name as argv[1], and the public key itself (in some canonicalized form) on stdin. The parent ssh process would wait() on this subprocess. The subprocess returns 0 (accept, continue), or non-zero (abort connection), optionally producing debugging information on stderr.
This is solved in patches attached to bz#1663
I don't think this is actually solved in the patches attached to 1663. https://bugzilla.mindrot.org/attachment.cgi?id=1811 only addresses sshd (the daemon), but this bug (1777) addresses ssh (the client).
This is possible to do, but without some significant changes is likely to be fairly inefficient. ssh reads known_hosts a couple of times during connection. At least once to figure out what host key algorithms are in use, then again to verify the hostkey sent and (optionally) a couple of times to deal with UpdateHostkeys messages from the server. This could result in the KnownHostsCommand being run a bunch of times and, unless it was very efficient, could make ssh pretty slow.
(In reply to Damien Miller from comment #3) > This is possible to do, but without some significant changes is > likely to be fairly inefficient. > > ssh reads known_hosts a couple of times during connection. At least > once to figure out what host key algorithms are in use, then again > to verify the hostkey sent This kind of information is host specific, and seems like it could be directly cached instead of re-read. is this the sort of significant changes you're talking about, or is there more that needs doing? > and (optionally) a couple of times to > deal with UpdateHostkeys messages from the server. UpdateHostKeys seems like it's about modifying the stored keys, right? that's a different thing than just reading it. We'd need to specify some sort of interface for sending back updates to the KnownHostsCommand as well, and this isn't something that was specified in the initial feature request. > This could result in the KnownHostsCommand being run a bunch of > times and, unless it was very efficient, could make ssh pretty slow. even with caching and a single run for reading, a slow KnownHostsCommand will make ssh pretty slow, in the same way that the existing ProxyCommand can also make ssh pretty slow. This is a tradeoff that someone configuring a KnownHostsCommand would need to make explicitly, but i don't think should rule it out as a feature.
Here's an implementation that embraces the inefficiency (it invokes the command up to three times per connection) and doesn't try to interact with UpdateHostKeys. https://github.com/djmdjm/openssh-wip/compare/KnownHostsCommand?expand=1
This has been committed and will be in OpenSSH 8.5
close bugs that were resolved in OpenSSH 8.5 release cycle