Date: Fri, 28 Sep 2001 11:55:24 -0600 From: Nate Williams <nate@yogotech.com> To: "Brian F. Feldman" <green@FreeBSD.org> Cc: nate@yogotech.com (Nate Williams), Kris Kennaway <kris@obsecurity.org>, Mike Silbersack <silby@silby.com>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/crypto/openssh atomicio.h auth-chall.c auth2-chall.c canohost.h clientloop.h groupaccess.c groupaccess.h kexdh.c kexgex.c log.h mac.c mac.h misc.c misc.h pathnames.h Message-ID: <15284.47500.388225.207808@nomad.yogotech.com> In-Reply-To: <200109281747.f8SHlhG59474@green.bikeshed.org> References: <nate@yogotech.com> <15284.36137.254842.551909@nomad.yogotech.com> <200109281747.f8SHlhG59474@green.bikeshed.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > > The only difference between this and what's in -CURRENT is that the > > > > > default /etc/ssh/ssh_config sets "Protocol 1,2" for all hosts. This can > > > > > be overrided entirely in user ~/.ssh/config files, as always. > > > > > > > > Are there known compatibility problems with version 2 that this works > > > > around, or is this just so that people don't get surprised when they need > > > > to verify a new host key? > > > > > > If you change the protocol to 2,1 then your version 1 RSA keys won't > > > be used by default > > > > Ok so far. > > > > > because if the server can speak the ssh2 protocol > > > then the client will try to auth with SSH2 keys first (which probably > > > wont be set up to work, or may have different passphrases, etc) and > > > then fall back to SSH2 password auth. > > > > So, in other words, there is really no point in having both protocols > > listed in the same line, since only one protocol is ever attempted. > > > > A better description of the protocol line woudl be: > > > > "Protocol 1" > > *OR* > > "Protocol 2" > > > > Since in fact, it doesn't try the first protocol, and if it fails, then > > try the second protocol. It always sticks with the primary protocol. > > It does try both, according to the preference order you specify. The > problem is then that it doesn't try the other protocol if the first one > fails at authentication. Umm, so it doesn't try both. Case 1: Protocol 1, 2 ------------- SSH2 connection attempt - SSH2 attempt fails at authentication due to no SSH2 authentication on remote - No retry at SSH2 because of authentication failure. SSH1 connection attempt - SSH1 succeeds - No retry necessary SSH1 connection attempt - SSH1 fails - No retry at SSH2 because of authentication failure. Case 2: Protocol 2, 1 SSH2 connection attempt - SSH2 succeeds - No retry necessary SSH2 connection attempt - SSH1 fails - No retry at SSH1 because of authentication failure. SSH1 connection attempt - SSH1 attempt fails at authentication due to no SSH1 authentication on remote - No retry at SSH2 because of authentication failure. The only thing I can think of where this might work is the case where the remote server supports both SSH1 and SSH2. However, in this case, it never falls back to using the other protocol since it always prompt for a password, thus causing the initial protocol authentication phase to *always* fail or *always* succeed. The secondary protocol can never be attempted, because the first protocol must *always* succeed or fail by definition of the protocol. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15284.47500.388225.207808>