On Friday, October 01, 2004 12:33:09 +0200 Niels Möller <nisse%lysator.liu.se@localhost> wrote:
Damien Miller <djm%mindrot.org@localhost> writes:This isn't entirely true: you can specify "method1,method2,method3" and sshd will allow authentication using method3 if the method1 and method2 don't exist. I'm not sure what you would have us do: kbdint doesn't seem to provide a way for a server to report supported methods to a client and I don't think it is correct to just ignore what a client has specified and continue with a random method that the server picks.I think the following three steps would improve the situation: 1. Require the names listed in the submethods field to be proper ssh names. I.e. standardized names without @, local/vendor stuff with @domain attached. Encourage documentation of the @domain things that implementations support.
Good.
2. Allow the server to use methods not on the client's list, in case none of the listed methods is implemented or configured for use by the server. (For methods that are implemented and acceptable for the server, the server should respect the client preferences).
Hrm. I guess I'd prefer to do this only when the client sends an empty list, indicating "any method is OK". This is particularly useful if the client wants to mix other methods in with the kbd-interactive ones in its list of things to try. For example, the client might want to try mechanisms in this order:
external-gssapi gssapi-with-mic/kerberos kbd-interactive/challenge-response-token public-key(*) kbd-interactive/one-time-password kbd-interactive/pam password(*) The key pair actually resides on a smart card, and we want to try the token they can look at before the one they have to insert into the machine.
3. Use the name field in the SSH_MSG_USERAUTH_INFO_REQUEST (or introduce a new field, if the "name" field is intended for the UI) to tell the client which method the server has selected. This way, the client can know if the server is about to ignore its submethods preferences, and can abort the keyboard-interactive if it so wishes.
Good.I agree the approach you describe would improve the situation. It is entirely possible that a PAM-based implementation will not in reality be able to tell what the backend is really doing or assign different method names to different backend modules. This is particularly complex as it may be the case that multiple modules will be used in the same conversation, and it is sometimes fuzzy where the line is (for example, a module may use a password answer collected by a previous module).
IMHO the solution to this would be for PAM-based implementations to use a single submethod name to refer to the whole PAM mess. That way, the server can say to the client "I'm using PAM, but I can't tell you more than that".
In addition to the changes you propose, I think further improvement can be had by providing a mechanism by which the client can request from the server a list of supported submethods. This is necessary if the client wants the user to select which methods should be tried and in which order.
-- Jeff