Created attachment 2337 [details]
Cache the host key and compare against it when re-keying

Proposal: Cache server host key after initial key exchange

Currently, whenever a key exchange is triggered, the host key offered by
the server must be verified. This may involve DNS queries or requests to
read the known hosts files. This can be problematic if
StrictHostKeyChecking is set to "yes" and the verification fails due to
a temporary problem, such as a corrupted /etc/ssh/ssh_known_hosts file.

It should also be noted that with increasing file transfer rates and
server-side support for time-based re-keying, the overhead of frequent
host key verification becomes more of an issue.

For example, consider an environment where /etc/ssh/ssh_known_hosts is
centrally managed and is the primary source for verifying the
authenticity of hosts. Further, assume that StrictHostKeyChecking is set
to "yes" and that a damaged copy of the ssh_known_hosts file is
distributed to the client systems. Existing ssh connections which re-key
while the damaged file is in place will fail to re-key and will then
disconnect. This will tend to impact high-bandwidth connections, such as
large file transfers or busy X11 sessions. It can also impact regular
login sessions if time-based re-keying is enabled.

To avoid these issues, it might be worthwhile to cache the host key used
during the initial key exchange. On subsequent key exchanges, the cached
copy of the previously verified host key could be compared against the
offered host key to avoid some of the overhead.

An initial patch has been attached to this bug, but I'm not sure if it
has unintended any side-effects.