---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,
as well.
 
Here is the section of ssh(1) related to it:

     StrictHostKeyChecking
          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''.


 --johan