Date: Fri, 28 Sep 2001 14:17:13 -0400 From: Kutulu <kutulu@kutulu.org> To: nate@yogotech.com (Nate Williams) Cc: "Brian F. Feldman" <green@FreeBSD.ORG>, 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: <5.1.0.14.0.20010928135816.009fb040@127.0.0.1> In-Reply-To: <15284.47500.388225.207808@nomad.yogotech.com> References: <200109281747.f8SHlhG59474@green.bikeshed.org> <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
At 11:55 AM 09/28/2001 -0600, Nate Williams wrote: >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. As with most sshd options, the server is supposed to tell the client which version(s) is supports, and the client picks one. The Protocol option in sshd_config merely lists which versions the server is supposed to offer. The Protocol option in ssh_config tells the client which to prefer. The first version number, in order, from the client config that is also supported by the server, is used. Once this is done, the connection is established and using SSHv1 or SSHv2. Then the authentication begins. At this point the protocol version is set in stone. Changing it would require breaking down the connection and going back through the entire negotiation phase again. The server tries the various configured authentication methods, again in order. If the user is unable to authenticate via e.g. public key, it falls back to password authentication. If the user is unable to authenticate by any means, then the assumption is that the user is simply not who they claim to be. Then authentication 'fails'. The issue is not a matter of SSH1 vs. SSH2 or properly negotiating which version to use. The issue here is simply that a user will have different keys for SSH1 and SSH2, or none at all for one version, and may attempt to use a private key that doesn't match the public key. Choosing a default of 1,2 means that the bulk of existing RSA SSH v1 keys will continue to work correctly, and the user is able to set up SSH v2 keys on thier remote hosts if they wish. --K 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?5.1.0.14.0.20010928135816.009fb040>