[EMAIL PROTECTED] on 2000.07.19 16:01:47
>>>>>> "NLY" == Noel L Yap <[EMAIL PROTECTED]> writes:
>
>>> If OpenSSH client will always send wrong info (I mean username and
>>> password here), then cvs-server will never authenticate it ;)
>
>NLY> I think we're arguing different points here. My point is that
>NLY> the OpenSSH client can send over a valid CVS username and
>NLY> password. It's just that the username/password doesn't belong to
>NLY> the client.
>
>I can't understand how you can call "valid" u/p that do not belong to
>the client. Who thinks of them as valid?
>From the top. My proposal was to have client CVS send the client username
over to the server for its use. Server CVS will still run as the server
user but will record the client username within its logs. For example, if
I am nyap on the client and I set
CVSROOT=cvsuser@cvsserver:/home/cvsgroup/.cvsroot,
I will be cvsuser on host cvsserver, but CVS will know me as nyap (ie it'll
log my actions as nyap).
Now, about security, cvsuser will need access to the repository. nyap will
need valid keys to become cvsuser. If nyap gives those keys away, others
will be able to act as cvsuser (unless the keys are limited to use by
nyap (SSH currently doesn't have such an option 'cos the server can't guarantee
that the username info sent by the client is valid)).
If nyap should not have access to the repository, he shouldn't be given keys.
So only one key pair is necessary and sufficient to allow nyap access to the
repository. Anything else is excess.
>Hm. Probably I've been a little incosistent in previous letter. Yes,
>you need _two_ passwords, one for ssh and and another for pserver.
>But the first password is rather irrelevant to CVS.
I see no need for two passwords, if you want the user to have access to the
server, give them keys (or a password). If you don't want them to have access
to the repository, manage permissions so that they don't have access. What's
the problem?
>NLY> IOW, it doesn't protect against non-repudiation.
>
>Huh? Sorry, I've looked up the word in dictionary, but it didn't make
>the phrase clearer. That's just my English terminology problem. And
>the abbreviation is unknown to me...
Here's a definition I found:
>Non-repudiation - adj. - A feature of a system that provides evidence that can
>be used, together with expert testimony about the validity of an entire
>identification infrastructure, against an attempt to repudiate an act.
In the context of my statement, it means that all the SSH server can ever know
is that the SSH client is allowed to have access. It can never know for certain
who is at the client's end.
In CVS's context, having the SSH client send over the client username is no
better
(security-wise) than having the CVS client send over the username. This is what
I meant by wanting to implement it in CVS rather than in SSH.
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.
