Hi,
Balazs Scheidler <[EMAIL PROTECTED]> writes:
> I address this message especially to Niels in the hope that he will able to
> respond. I plan to work a bit on user authentication, more exactly I would
> like to add publickey authentication.
Sorry for the late reply. I just got home from some vacation, and I'll
leave again on Wednesday. This time for the Chaos Computer Club Camp
at Berlin. So I'll try to answer your questions right away.
> The current scheme is a simple userauth class, which gets the whole
> SSH_MSG_USERAUTH_REQUEST packet, and must return the result immediately. The
> problem with this approach is that some methods need additional packets to
> be sent, so the decision cannot be made immediately.
As far as I can see, it should be enough to let the AUTHENTICATE
method return something more than a boolean yes-or-no answer. Off the
top of my head, it could have three three possible return codes,
FAIL = 0
SUCCESS = 1
OTHER = 2
where the latter case is needed only for sending the
SSH_MSH_USERAUTH_PK_OK message. In this case, the method could
allocate a reply packet and return it through an extra argument.
> I propose the following changes:
>
> the AUTHENTICATE method would get two additional parameters:
>
> * connection, so the authentication mechanism could send packets to the
> client. (in publickey, at least the message SSH_MSG_USERAUTH_PK_OK would
> be required)
I think it would be cleaner to have it return the packet, and not know
about the connection, but I guess that is a matter of taste. Passing
the connection should work fine, and perhaps we will find out that it
is needed for something else anyway.
> * command_continuation: where the authentication result should be returned
I'm not sure that this is really necessary, at this level. It seems
more natural to have the AUTHENTICATE method simply return the
immediate response to the authentication request. But I have to read
your code, and perhaps I'll change my mind. We do need some kind of
continuation at a higher level, but that should be taken care of by
the objects in server_userauth.c.
> I would add a new command_continuation class to server_userauth.c, which
> would do everything which is done immediately after AUTHENTICATE() now.
My OTOH proposal is to add an argument struct lsh_string
**other_response to the AUTHENTICATE method.
> AUTHENTICATE would then return to this command_continuation, which would do
> its job, and return to the original command_continuation passed to
> do_userauth().
I suspect this is overkill now. But that may change once we try to do
remote user database lookups (yp, nis+, radius, whatever there is) in
an asyncronous fashion.
> What do you think?
I have to read your code (and mine, I haven't looked much at it for
three weeks ;-). I hope it has not been too difficult to get publickey
authentication in. And I'm very curious to see what you have been doing
these weeks.
Regards,
/Niels
