]> asedeno.scripts.mit.edu Git - PuTTY.git/commit
Add manual cross-certification of new host keys.
authorSimon Tatham <anakin@pobox.com>
Mon, 21 Mar 2016 07:25:31 +0000 (07:25 +0000)
committerSimon Tatham <anakin@pobox.com>
Mon, 21 Mar 2016 07:38:31 +0000 (07:38 +0000)
commite786452cb2dbd190e3b72e68b08a261454151cbe
tree66d4b66679867401a6ce92a5ad39cef524e890bf
parent75fdfed80be41ca471c5a34184eeaf5b68bf42c0
Add manual cross-certification of new host keys.

If a server offers host key algorithms that we don't have a stored key
for, they will now appear in a submenu of the Special Commands menu.
Selecting one will force a repeat key exchange with that key, and if
it succeeds, will add the new host key to the cache. The idea is that
the new key sent by the server is protected by the crypto established
in the previous key exchange, so this is just as safe as typing some
command like 'ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub' at the
server prompt and transcribing the results manually.

This allows switching over to newer host key algorithms if the client
has begun to support them (e.g. people using PuTTY's new ECC
functionality for the first time), or if the server has acquired a new
key (e.g. due to a server OS upgrade).

At the moment, it's only available manually, for a single host key
type at a time. Automating it is potentially controversial for
security policy reasons (what if someone doesn't agree this is what
they want in their host key cache, or doesn't want to switch over to
using whichever of the keys PuTTY would now put top of the list?), for
code plumbing reasons (chaining several of these rekeys might be more
annoying than doing one at a time) and for CPU usage reasons (rekeys
are expensive), but even so, it might turn out to be a good idea in
future.
ssh.c