Sorry, I've gotta jump in for a minute... Greg is right about SSH v pserver, however.
> > There's only _EXACTLY_ one case where cvspserver is in any way more > > secure than giving out real accounts, and that's when > > pserver is used to > > give read-only anonymous access to a _copy_ of a repository. > > And if the copy needs to get sync'd back to the "real" > repository (a > definate requirement), there goes your security. Next idea? Read up on rsync via an ssh tunnel to do this. Sudo, and noshell for a non-priviliged role account are also advisable. > > In other words if you've given an account to an user to access a CVS > > repostitory hosted on your network then you _MUST_ do whatever is > > necessary to isolate that user's access from the data and > services on > > your network and in your systems that you do not trust them > to access. > > I.e. you give them limited trust. > > i.e. you give them no access. Hence, pserver. I don't > want to give > out shells to hundreds and thousands of developers using ssh. > Using pserver, > this works today, and is much more secure. I don't need > accountability, I > need security. pserver vs. ssh are not even _CLOSE_ to a > comparible item. Well, you're right here... security between ssh and pserver is not even close-- ssh is secure, and pserver is not. Also, you do not _need_ to provide the user w/ the ability to login. In fact, the account that gets created should be LOCKED to ensure it is not used. Next, lock down the ssh key on the server end; read up on how to tell SSH it can exec exactly ONE command-- cvs only needs one. > > In other words you must comparmentalize access to your shared CVS > > repository so that remote users can gain secure access to > it while not > > gaining access to anything you don't want them to access. > > Gee, sounds like pserver again. Once you hand out an > ssh account, > you give them a huge truck to drive through your wall of security, > authenticated and validated.. with absolutely _NO_ > verifyability that the > user on the other end is who you think it is. Not so. You're creating a tiny pin hole, and it's very easily closed by revoking the user's key pair on the server. > It's an interesting idea, however.. not usable as users > scale into > the thousands. Well, key management is a bit of work, and so is setting up a well hardened cvs server. The key mgmt part it's easily scripted. If I had more than a dozen users that's what I'd advise scripting the administration. I'm actually completing a setup aas described, and will be happy to share it w/ the list when I have a bit more time. I just wanted to add my 0.02 in defense of the SSH solution. For an externally facing server it's the only sane thing to do. -Dou _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
