You can also use $HOME/.ssh/environment on the client side to tunnel environment variables of your choice. I've never tried it myself, I just saw that in the ssh man page. (Your developers would be able to cheat, though.) The trouble is, CVS doesn't look at the environment to decide who's calling.
My script that runs in the command="" option in the authorized_keys2 file runs successfully and I can control the input based on which key (ie, which developer) is used. I am looking for the correct environmental variable that CVS WILL look at.
There HAS to be a way to force cvs to record the correct committer name.
Why ? Why would cvs extract that information from a source other than its own euid ?
I just can't imagine that this hasn't been required before: a single shell account with a used id of, for example, 'cvsuser' requiring SSH, instead of pserver, authentication and access for developers. The nature of CVS, that of tracking diffs and who did what when, seems to be compromised in this situation. Thats all.
I have to agree with you here. There seems to be an attitude of "CVS doesn't do this therefore I can't see why on earth you would want to" in all of the responses to your request. The other posters seem blinkered by a last-generation "login" paradigm (despite the existence of pserver). I suspect this attitude may be born of an ignorance of how SSH works and what it is capable of.
In fact what you want to do is just the recipie given in the O'Reilly book on CVS (usually a very reliable reference), and uses the SSH configfile to set the environment variable LOGNAME. The O'Reilly book
says this works, but CVS currently ignores LOGNAME unless the uid is
zero so I can only guess that the behaviour was disabled at some
previous release of CVS.
It's easy enough to patch the source to re-enable the previous behaviour
-- it's a 2 liner. I use a patched CVS to manage secure authentication
for a restricted-access repository using exactly the scheme you propose.
It works very successfully and has considerable advantages regarding login tracking and individual user authentication. Wen you need the
ability to grant or deny access on an individual basis and track access
it's a highly capable method.
No doubt there will be some ill-founded response to this worrying about
security in some vague manner. But it's very easy to ensure that authorised users can do nothing outside CVS. I advise using the SSH config file to only allow execution of the "cvs" command, and for belt and braces run the account as a restricted shell (in case of any future security hole discovered in ssh or cvs).
Keith Refson
_______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
