Fw: need to force username of cvs 'action' when using shared SSH account

[Keith Refson]

 "Tim Grotenhuis" <address@hidden> wrote:

> > > 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