Andrew:
At 08:15 AM 2/7/99 -0800, someone using Andrew Morgan's login wrote:
> a. add some generic message exchange types to the client and the
>server (echo'd prompt, invisible prompt, binary prompt (raw data
>exchange) etc..)
Yes and this has to be properly defined to be generic enough so that it
will stable in the future. Piece of cake! :-)
> b. add an interface to PAM to the server to abstract the
>authentication method which can drive the (a.) message exchanges.
Yes.
>
> "We could add (a.) and make it the generic interface for doing
>authentication exchanges under ssh2. PAM-support would then look like
>'just another' authentication type which makes use of generic message
>exchange mechanism."
>
Yes, but I would say : "We could add (a.) and make it the generic interface
for doing *NEW* authentication exchanges under ssh[2|1]."
It's important to keep all the existing authentication protocols without
any changes for compatibility reason.
Also, it is a nice option to have, as a fallback protocol, a predefined
authentication protocol, to be used if the client does not support the
*new* generic authentication.
I explain:
if I setup a server to use *only* the new generic authentication protocol,
and PAM as authentication mechanism, but if I want it still to accept *old*
clients which do not have this protocol built in, I may choose to enable a
pre-defined authentication protocol as a fallback(Let say the password
protocol for ex.)
I know that for such *old* clients, I won't be able to change their prompt,
or that more complex challenge won't be handled properly (multiple
challenge) but it should be *good enough* for most of the requests.
The authentication method is still the same (PAM in this case) but a
deprecated authentication protocol may be used to talk with old clients.
I have done that on the securID patch I've done to handle correctly the
different modes of securID and the fallback mechanism is really nice.
jean
>This sounds like a noble goal. If it can be attained, I'd be really
>happy to see/use it.
>
>[Why, given the choice, anyone would not actually want to use PAM I'd be
>interested to discuss (off line).]
>
>Cheers
>
>Andrew
>
>
>
>
>Jean Chouanard wrote:
>>
>> Yes but... Cannot we do better ? :-)
>>
>> Not all systems have PAM or (want to) use it, and we know that the main
>> problem to add a new authentication scheme to the ssh protocol is to have
>> to modify both the client and the server to implement this as a new
>> authentication protocol.
>>
>> So why don't we split this ssh-PAM-patch in two:
>>
>> * Support for the generic authentication protocol as pre-defined
>> authentication method between the client and the server (and perhaps
>> enlarge this method to be able to handle any needs for authentication).
>> * An optional module to add PAM support for the server side, using this
>> generic authentication.
>>
>> Thus, any new authentication methods can either be implemented through PAM
>> (if PAM is used on the ssh server) or they can be coded as a server module
>> using the generic authentication to communicate with the client.
>>
>> Don't you think it will be more valuable?
>>
>> jean
>>
>> At 10:10 AM 2/5/99 -0800, someone using Andrew Morgan's login wrote:
>> >If anyone is interested in integrating it into ssh2, there is an old
>> >piece of prototype code for adding complete PAM support to ssh1 (client
>> >and server) here:
>> >
>> >ftp://ftp.kernel.org/pub/linux/libs/pam/pre/applications/ssh-PAM-patch.2.ta
>> r.gz
>> >
>> >If enough people were to make the statement that they'd like to see this
>> >type of thing supported by ssh2, and someone wants to offer me a little
>> >help, I'd be willing to forward port this patch.
>> >
>> >I happen to know that this patch is happily used by a number of people,
>> >and I believe that more would want to use it, if it was part of the
>> >official distribution.
>> >
>> >Cheers
>> >
>> >Andrew
>> >
>> >Frank Cusack wrote:
>> >>
>> >> In message <>,
>> >> Martin Forssen writes:
>> >> > ---2137996019-851401618-918144200=:24784
>> >> > Content-Type: TEXT/plain; charset=us-ascii
>> >> >
>> >> > Attached below follows a proposal for a new authentication method for
>> >> > SSH2. This new method implements general challenge-response
>> >> > authentication.
>> >> >
>> >>
>> >> I think that a better method would be one that I proposed earlier. :)
>> >> I have implemented it for ssh1 already. I call it "password-plus".
>> >> [I haven't implemented it for ssh2 due to licensing restrictions.]
>> >>
>> >> The "problem" with the "challenge-response" method is that the server
>> >> may not know ahead of time (ie, solely from the username) if a user
>> >> requires challenge-reponse or standard password auth. eg. when PAM
>> >> is used as the backend.
>> >>
>> >> Of course, if the user only requires password auth, no harm, no foul;
>> >> the "challenge" is simply the password request and the response is
>> >> simply the password. But, personally, I'd rather that the name be
>> >> more indicative that this is a generalized authentication, and
>> >> /not neccessarily/ challenge-response.
>> >>
>> >> Another problem is if multiple challenges are required.
>> >>
>> >> Another useful generalization is to support multiple messages in
>> >> a single "challenge". As an example, if the backend (eg PAM) is
requesting
>> >> a password change and wants to prompt the user twice for the new
>> >> password, both prompts would be in a single "challenge" message.
>> >> A GUI client could then display both prompts in a single window.
>> >>
>> >> I have the original text of my proposal around here somewhere if anyone
>> >> is interested, however the last time I proposed it I got no responses.
>> >>
>> >> ~frank
>> - jean -
- jean -
