On Thursday, September 30, 2004 15:34:08 +1000 Damien Miller <djm%mindrot.org@localhost> wrote:
Peter Gutmann wrote:That's exactly the problem I ran into. There are Linux systems now shipping that have OpenSSH set up to only allow keyboard-interactive auth, but the auth they're tunnelling through keyboard-interactive is standard password auth. Maybe the spec should state that where ambiguities exist (i.e. there are several ways to do the same thing), the simplest method and/or the one in the main RFC drafts should take precedence.That is silly. It would require a SSH server implementation to somehow peek into what authentication methods PAM is using so that it could ensure that is isn't inadvertantly offering PAM password authentication in "keyboard-interactive" instead of PAM auth via "password".
Of course, the administrator knows how PAM is configured, and if the only method they will be using is checking passwords against the UNIX passwd file, then they can configure "password" support. But if they want, say, Kerberos, which is supported by a PAM module, then turning on "password" will DO THE WRONG THING.
In this configuration OpenSSH is not "tunneling standard password". It's not "tunneling" anything; keyboard-interactive is not a wrapper around other userauth methods; it is its own method. The "password" method is "the user sends a password up front, which the server either accepts or not". That is not what keyboard-interactive does, and it is not how PAM works -- the model used by both of those is "ask the user a question; get an answer; repeat until you have everything you need". In some cases there is only one question which happens to be "what is your password?", but that is entirely up to the underlying PAM module which is making the determination as to who the user is and whether they should be allowed in.
We can argue all we want about whether the model PAM uses is good or bad, but we are not in this working group going to change how PAM works, or the fact that SSH servers have to support it, or the fact that people will want to configure their machines with complex mechanisms that require a challenge, or more than one round trip, or something that is only available to them as a PAM module.
We can argue all we want about whether it is a good or bad thing that Linux distributions come with OpenSSH configured to support keyboard-interactive but not password, but we are not in this working group going to change the fact that those vendors use PAM and support mechanisms that fall into one of the aforementioned categories. And, we cannot tell people how they must configure their machines.
RFC2119 requirements language is not about assuring that all instances of everything will interoperate. It's about making sure that, given any arbitrary combination of implementations, it is _possible_ to configure them in an interoperable way. In practice, it is often not possible to get both complete interoperability and the features you want. Linux distributors want to support user login via Kerberos or challenge/response tokens or icky try-sending-a-password-to-LDAP-and-see-if-it-works, not to mention whatever other things someone comes up with in the future, and to accomplish that in a clean way they give up interoperability with ssh clients that don't support "password".
As an operator of a distributed computing facility where support for our infrastructure including authentication is an absolute requirement, and as someone who is getting tired of porting an ancient 4.2BSD login to every new platform, I support that decision. It will make life a lot easier for me and a lot of other people, at the expense of making life slightly harder for the handful of people who have these machines and want to allow remote password-based (not public-key) ssh connections from clients which don't support keyboard-interactive, by requiring them to <gasp> change a config file.
-- Jeffrey T. Hutzelman (N3NHS) <jhutz+%cmu.edu@localhost> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA