Re: Multiple simultaneous userauth requests

[nisse%lysator.liu.se@localhost (Niels Möller)]

"Joseph Galbraith" <galb-list%vandyke.com@localhost> writes:

> The userauth draft contains this text in section 2.2:
> 
> > The client MAY send several authentication
> > requests without waiting for responses from
> > previous requests.  The server MUST acknowledge
> > any failed requests with a SSH_MSG_USERAUTH_FAILURE
> > message.  However, SSH_MSG_USERAUTH_SUCCESS MUST
> > be sent only once, and once SSH_MSG_USERAUTH_SUCCESS
> > has been sent, any further authentication requests
> > received after that SHOULD be silently ignored.
> 
> This seems overly complicated?  Do any clients
> actually do this?

lsh does. This way, the client can send a none request, immediately
followed by a publickey requests (without any actual signature) for
each available public key.

Next the client processes the replies in order, if it gets any
USERAUTH_SUCCESS response (could happen with anonymous services, or
with kerberos or srp key exchange) it goes on doing whatever it wanted
to do after login. If it receives any SSH_MSG_USERAUTH_PK_OK response
it computes a signature for the correspondign key and sends that. If
it receives USERAUTH_FAILURE for all of the requests, and the server
indicates that password authentication might work, it asks the user
for a password and sends a password request.

I think it is nice to be able to do this without having to wait a full
roundtrip for a reply between each request. It did add a little
complexity to my server, but the simplest way to deal with it is to
let the server work with one userauth request at a time.

When you receive a userauth request, simply don't read anything more
from the client until the userauth request is completely processed and
replied to. At that time, you *know* whether or not the userauth phase
is over, and if it is, you redirect all future userauth requests to
/dev/null.

The reason my implementation got a little complex is that I haven't
yet forked when processing userauth requests, and I want to support
password authentication methods that require communication with remote
host, and thus need to return the main select loop before any reply
can be sent.

I also believe it is bad protocol design in general to require clients
to wait unnecessarily. If a server wants to process a single request
at a time or do some other serialization, it can just do that, it
should not push that responsibity to that clients (and even if it
does, it can't rely on clients behaving properly).

Regards,
/Niels