On Wednesday, September 29, 2004 03:47:16 +1200 Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost> wrote:
nisse%lysator.liu.se@localhost (=?iso-8859-1?q?Niels_M=F6ller?=) writes:The default openssh configuration for some linux distributions have disabled plain "password" authentication in favour of keyboard-interact, my guess is that they do this in order to work better with PAM.That was where the example I used in my message came from: Standard "password" is disabled, and if you send "password" as the submethod OpenSSH immediately drops the connection with a userauth-failed response. OTOH if you leave submethods empty, the same "password" authentication succeeds without any problems. This behaviour is compliant with the spec, but only because execl( "/usr/games/hack", ... ) would also be compliant with the spec.
OK; I'm confused. In your last message, you seemed to be saying that the user had entered "password" as the submethod list because they were just randomly making something up instead of actually using the name of a submethod the server supports. Now you seem to be saying that the user is trying to stuff the name of an ssh userauth method into the submethod field, which is _not_ a list of ssh userauth methods. Which is it?
Either way, I have no sympathy. The point of this knob is to allow for cases where the user knows what submethods the server supports and has a reason for requesting a particular submethod or list of submethods, rather than using the server's default behaviour (which is presumably the result of configuration by the server's administrator, possibly of something not specific to ssh).
If the user does not know what submethods the server supports, they should leave this field blank.
(That's pretty weird behaviour: You can't send it a standard password, but you can send it the password dressed up as keyboard-interactive auth provided you don't tell it that it's a password).
You mean, that you don't randomly make up a submethod name that the server has never heard of? Well, yes.
It also makes it extremely difficult to implement in any app that doesn't have a UI, i.e. where you can't just keep asking the user for input until the server is satisfied. Fortunately for standard password auth I've never found anything that sends more than one prompt, but I'd like to see a bit more consideration given to non-interactive apps. Currently the draft seems to assume that the client-side is tied to a live user in front of a terminal who can read, interpret, and respond to each prompt, which isn't always the case.
Well, the name of the method is "keyboard-interactive", which pretty much implies that there _is_ a live user you can interact with. For some of the underlying authentication schemes there is nothing you can do about this.
It is worth noting that many of the Linux distributions of which Niels speaks use PAM for all of their "initial authentication" needs as well as for accounting and session management. OpenSSH implements keyboard-interactive using PAM, but it does _not_ implement "password" that way. This means that if you expect to use PAM to authenticate user logins, then the server must be configured not to support "password".
-- Jeff