Date: Fri, 28 Sep 2001 12:52:51 -0600 From: Nate Williams <nate@yogotech.com> To: Kutulu <kutulu@kutulu.org> Cc: nate@yogotech.com (Nate Williams), "Brian F. Feldman" <green@FreeBSD.ORG>, 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.50947.796628.489197@nomad.yogotech.com> In-Reply-To: <5.1.0.14.0.20010928135816.009fb040@127.0.0.1> References: <200109281747.f8SHlhG59474@green.bikeshed.org> <nate@yogotech.com> <15284.36137.254842.551909@nomad.yogotech.com> <5.1.0.14.0.20010928135816.009fb040@127.0.0.1>
next in thread | previous in thread | raw e-mail | index | archive | help
> >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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15284.50947.796628.489197>