From owner-cvs-all Fri Sep 28 11:53: 4 2001 Delivered-To: cvs-all@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 5C2DD37B406; Fri, 28 Sep 2001 11:52:56 -0700 (PDT) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id MAA07941; Fri, 28 Sep 2001 12:52:53 -0600 (MDT) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id MAA27826; Fri, 28 Sep 2001 12:52:52 -0600 (MDT) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15284.50947.796628.489197@nomad.yogotech.com> Date: Fri, 28 Sep 2001 12:52:51 -0600 To: Kutulu Cc: nate@yogotech.com (Nate Williams), "Brian F. Feldman" , Kris Kennaway , Mike Silbersack , 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 In-Reply-To: <5.1.0.14.0.20010928135816.009fb040@127.0.0.1> References: <200109281747.f8SHlhG59474@green.bikeshed.org> <15284.36137.254842.551909@nomad.yogotech.com> <5.1.0.14.0.20010928135816.009fb040@127.0.0.1> X-Mailer: VM 6.95 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > >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. > > You seem to be confusing the authentication step with the negotiation step. > > When an ssh connection comes in, the server first negotiates the protocol > version, ciphers, and does a key exchange with the client. At this point, > the "Protocol x, y" option comes into play. There are basically three > options for each end of the connection: > > o Server/Client supports only SSH v1 > o Server/Client supports only SSH v2 > o Server/Client supports both > > In the first two cases, if the remote end supports the same version as the > local end, they use that version. If not, the connection fails. In the > case where both ends support multiple versions, the "Protocol" > configuration comes into play. That makes sense. In most of the cases, I have a client that supports both, and a server that supports both. What I was *hoping* would happen would be that in the case where the server supports both, it would check if the user has an SSH[12] key, and if not fall back to the alternative protocol. What you are saying is that once a 'protocol' has been agreed upon, it never falls back to a different protocol upon failure, which is what I thought the documentation implied. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message