Re: secsh-userauth

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

Tatu Ylonen <ylo%ssh.com@localhost> writes:

> If the user name changes, it is critical that all such cached
> data/credentials is destroyed before starting to authenticate as another
> user.  If we permit leaving such globally stored data/credentials hanging
> around when the user name changes, we may end up in a situation where
> first trying to (partially) authenticate as one user and then as another
> user gives you more rights than directly trying to authenticate as
> yourself.

Even if servers are permitted to disconnect, or stop responding
usefully to userauth requests, once the user name changes, I consider
such behaviour abnormal.

The recommended way to deal with user name change ought to be to throw
away any accumulated state and start over trying to authenticate the
new user.

In some cases (like strange PAM or kerberos interfaces you refer to,
or for an implementation that irreversibly changes it uid when
processing the first userauth-request) authenticating a new user may
be difficult or impossible, so I agree that behaviour you and Markus
describe should be allowed. But I don't think the spec should
recommend it.

For an extreme example, consider a userauth request with username ""
and method "none", followed by a request with username "nisse" and
method "password". There may be some odd configuration where the first
request actually succeeds, but except for that, I see no reason for
the server to collect any state that it is hard to throw away.

I view userauth requests processing as a logically stateless process
(at least as long as there are no "partial successes"). The server may
cache user information between requests, but I view that only as an
optimization.

Regards,
/Niels