From owner-cvs-all Fri Sep 28 12:24:56 2001 Delivered-To: cvs-all@freebsd.org Received: from pr0n.kutulu.org (pr0n.kutulu.org [151.196.107.157]) by hub.freebsd.org (Postfix) with ESMTP id 6C0B237B410; Fri, 28 Sep 2001 12:24:43 -0700 (PDT) Received: from kutulu.kutulu.org ([64.212.128.3]) by pr0n.kutulu.org (8.11.6/8.11.6) with ESMTP id f8SESs715942; Fri, 28 Sep 2001 14:28:54 GMT (envelope-from kutulu@kutulu.org) Message-Id: <5.1.0.14.0.20010928142424.009fcac0@127.0.0.1> X-Sender: kutulu@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 28 Sep 2001 14:53:48 -0400 To: nate@yogotech.com (Nate Williams) From: Kutulu 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 Cc: Kutulu , nate@yogotech.com (Nate Williams), "Brian F. Feldman" , Kris Kennaway , Mike Silbersack , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG In-Reply-To: <15284.50947.796628.489197@nomad.yogotech.com> References: <5.1.0.14.0.20010928135816.009fb040@127.0.0.1> <200109281747.f8SHlhG59474@green.bikeshed.org> <15284.36137.254842.551909@nomad.yogotech.com> <5.1.0.14.0.20010928135816.009fb040@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 At 12:52 PM 09/28/2001 -0600, Nate Williams wrote: >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. The reason this isn't really feasible is that, the way the SSH RFC's are written, the authentication layer is essentially a 'service' of the transport layer. The authentication layer cannot begin to operate until the transport layer has done the server/client key exchanges and protocol negotiation. However, before the authentication layer starts, there's no concept of a user. There's also no means for the server or client to renegotiate the entire process from scratch, short of disconnecting and reconnecting. The end result is, the server can't possibly know, in time to alter the protocol choice, what keypairs the user logging on has defined. --K To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message