Subject: Multiple simultaneous userauth requests

From: "Joseph Galbraith" <[email-masked]>
Date: Thu, 29 Nov 2001 16:04:00 -0700

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?

Can't we make things easier on implementers and
just say the multiple simultaneous userauth requests
are illegal?

- Joseph

---

From: [email-masked] (Niels Möller)
Date: 30 Nov 2001 18:16:25 +0100

> This seems overly complicated?  Do any clients

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