On Thursday, September 30, 2004 17:09:52 +1200 Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost> wrote:
Jeffrey Hutzelman <jhutz%cmu.edu@localhost> writes:On Wednesday, September 29, 2004 03:47:16 +1200 Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost> wrote:(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.So OpenSSH's behaviour is as follows: 1. It immediately rejects attempts to auth.using any method it hasn't heard of. 2. The methods it doesn't reject are undocumented.
I'll agree that's somewhat unfortunate, and I imagine it wouldn't hurt to change. Note that I have nothing to do with OpenSSH, so I can't do anything about it in any case.
OTOH, "implementation-defined" does translate to "don't use this unless you know in advance what it will do". The expected behaviour is that clients won't set this field unless the user tells it to, and that users won't do that unless they know what is the correct thing to request. It's not expected that a non-empty value will work with a server whose capabilities you don't know in advance -- doing that would require creating a submethod registry, which moves us beyond the realm of "implementation-defined".
That said, from a UI standpoint it seems like it would be useful to have a mechanism by which the server can choose to report what submethods it supports and provide a description for each, so that client can present the user with a set of choices.
-- Jeff