[Bug 2154] New: Avoid key lookup overhead when re-keying

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=2154

            Bug ID: 2154
           Summary: Avoid key lookup overhead when re-keying
           Product: Portable OpenSSH
           Version: -current
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: imorgan at nas.nasa.gov

Created attachment 2337
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2337&action=edit
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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.