Subject: Re: Proposal: Disable SSHd Protocol v1 by Default (WAS: Re: ssh config path change (/etc -> /etc/ssh))
To: None <firstname.lastname@example.org>
From: Johan A. van Zanten <email@example.com>
Date: 03/14/2002 16:37:56
---In message <20020314211410.GA13302@rek.tjls.com>
>Uh, beg pardon, but there is a man-in-the-middle attack possible on *any*
>protocol that uses public-key authentication, when the key for the other
>end cannot be validated. This is as true of SSHv2 as it is of SSHv1; it
>could be overcome by using PKI but nobody has done that.
>It would be foolish in the extreme to assume that using v2 protects you
>against this _general vulnerability of public-key authentication systems_
>when, in fact, it does not. If you can't verify the other end's key, you
>are vulnerable to a man-in-the-middle attack, period -- whether you can
>use "dsniff" to exploit that vulnerability or not.
That all types of PK authentication is vulnerable to MITM attacks is a
very good point.
However, when deciding whether or not to make v1 disabled in the NetBSD
default config., should we not take into account that there is a
currently-available tool (dsniff) which can be used against v1 but not v2?
Of course, a tool may very well soon appear to be used against v2.
There is also the config keyword "StrictHostKeyChecking" which helps
prevent against these sorts of attacks. But making this the default is
bound to cause some confusion and trouble for people unfamiliar with
setting up SSH, just as limiting the protocol to v2 will.
But i think one issue we are discussing here is risk versus convenience,
so i would advocate consideration of making this a default config setting,
Here is the section of ssh(1) related to it:
If this flag is set to ``yes'', ssh will never automat-
ically add host keys to the $HOME/.ssh/known_hosts
file, and refuses to connect to hosts whose host key
has changed. This provides maximum protection against
trojan horse attacks, however, can be annoying when the
/etc/ssh/ssh_known_hosts file is poorly maintained, or
connections to new hosts are frequently made. This
option forces the user to manually add all new hosts.
If this flag is set to ``no'', ssh will automatically
add new host keys to the user known hosts files. If
this flag is set to ``ask'', new host keys will be
added to the user known host files only after the user
has confirmed that is what they really want to do, and
ssh will refuse to connect to hosts whose host key has
changed. The host keys of known hosts will be verified
automatically in all cases. The argument must be
``yes'', ``no'' or ``ask''. The default is ``ask''.