info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: How 2 Secure the repository?


From: Douglas Finkle
Subject: RE: How 2 Secure the repository?
Date: Mon, 11 Mar 2002 15:55:23 -0500

>> Environment: cvs 1.11.1p running on unix. Clients are mostly 
>> wincvs1.13.7+ 
>>(in-house modifications to prevent password display on the 
>> screen)

>> Huh?

> Huh what?

There's no need to use passwd... you should be using keys. The
passphrase does _not_ go in as p/o the CVSROOT definition. That's
why you are seeing it in WinCVS.

> plink for ssh connection.

>> Also, use Pageant on Windows. UNIX will require ssh-agent for 
>> the same functionality.
>>
> Pageant did us no good. plink does the ssh connection without a 
> hitch and does not hold the >connection open after the transaction 
> completes. Wincvs was another issue ... We/I modified >the code so when 
> you display the preferences window, the "Using:" message is not 
> displayed (it contains the password in clear text).

WinCVS handles plink just fine, but you need to use keys.

Pageant doesn't help b/c you're using passwd auth, and not public key
auth. Public key auth is a better solution if you really want
security. Pageant helps you do this while maintaining good passphrases.

>> Developers have valid login on unix server and are 
>> members of the cvs and users groups.
>> 
>> How do I protect the repository from developers modifying or 
>> deleting code directly without using cvs? Any protection scheme 
>> we've been able to think of either locks them out completely or 
>> has loop holes.
>
> You take away login access. Do this by setting their hashed passwd
> in /etc/shadow to "NP", and add a line to their SSH authorization file
> on the server side to _only_ allow the command 'cvs server'. The
> O' Reilly SSH book explains this pretty clearly.
>
>Taking away login access on THIS machine is not feasible ... however, 
> we are exploring the possibility of moving the repository to another 
> machine where this is not an issue.

Unless you can restrict access to this machine then you can't get any
better security or data integrity than to mandate it through your
security policy.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]