[EMAIL PROTECTED] on 2000.07.21 14:38:26
>I think Noel is referring still to the SSH client authenticating as a
>single UNIX user but then attempting to map to many CVS users.
I'm referring to many users SSH'ing into one user. If you had a one-to-one
mapping, there wouldn't be a problem (since the server username and the client
username tend to match anyway).
Now, the problem is that when you have the former, CVS will know you by the
server username. It will never record the client username. My proposal changes
that (but the client username can't be secure).
>I have
>been objecting to the part, as I understand the request and as I think
>you understood it, about not requiring passwords or other
>secure/semi-secure methods for the second phase authentication.
If CVS had such authentication, the first phase authentication shouldn't be
needed.
> I
>haven't studied your nserver model yet, but the conventional CVS has no
>2-phase authentication methods available.
IMHO, it shouldn't have any authentication. Authentication should be left to
secure software.
>If it is using any :ext:
>method (RSH, SSH, etc.) or pserver, the originally authenticated user
>name is what you will see in the logs, though you can map to a secondary
>user which the CVS server will run under - convenient for file
>permissions, though I would usually rather map each user to their own
>user ID and rely on the OSs users, groups, & file permissions to do that
>job.
Have you tested this? IOW, have you set CVS_RSH=/my/ssh and
CVSROOT=anotheruser@server:/my/cvsroot and done a commit? If this works the way
you say it does, my proposal isn't necessary 'cos that's exactly what its
purpose is. Also, I don't know where in the code it would do this (and believe
me, I've looked).
>I'm not sure Noel understands what we mean by authenticate. I just said
>this in a previous email, but an SSH server is relying on a standardized
>protocol and a password known (in theory) only to it and a particular
>user. It is irrelevant if an OpenSSH client has been hacked, because a
>malicious user with a "pure" client could have obtained the same
>information if they already had the user's password (or private key in
>some cases) and a "hacked" client which didn't have the correct password
>or which didn't support the protocol properly couldn't have authenticated
>anyhow.
Or, the "trusted" developer on the other side decides to get someone else in
trouble by sending over the wrong info (again, in a many-to-one mapping).
To recap: This proposal affects those using many-to-one mappings of users. It
is meant to "fix" CVS such that it logs the client username rather than the
server username.
Noel
This communication is for informational purposes only. It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan & Co. Incorporated, its
subsidiaries and affiliates.
