On Wed, Dec 09, 2015 at 04:44:31PM +0100, Vincent Lefevre wrote: > On 2015-12-09 15:18:44 +0000, Colin Watson wrote: > > On Wed, Dec 09, 2015 at 10:06:32AM +0100, Vincent Lefevre wrote: > > > According to what is documented, this appears to be related to > > > host key checking: the error mesage is "no matching *host key* > > > type found" and the option name is HostKeyAlgorithms. In what > > > way it could be insecure in the case where the user doesn't have > > > the key in the ~/.ssh/known_hosts file? > > > > Weak host keys make it easier to conduct man-in-the-middle attacks. > > My point is that with StrictHostKeyChecking = no and no keys for > the host in ~/.ssh/known_hosts, there is no host authentication, > so that a man-in-the-middle attack is already possible, even if > the server provides a strong key. Thus whether a weak host key > is provided by the server or not in this case shouldn't matter.
With StrictHostKeyChecking=yes/ask, it still weakens trust-on-first-use. With StrictHostKeyChecking=no, I can somewhat see your point (although there would at least be a visual indication if a different host key were presented); but I doubt that it's worth continuing to support otherwise obsolescent cryptography just for that case. Put another way: it'd be quite peculiar and confusing to send different server_host_key_algorithms in the client's SSH_MSG_KEXINIT packet depending on the value of StrictHostKeyChecking. -- Colin Watson [cjwat...@debian.org]
