Been watching this thread for a while... Here is my question: Are chrooted environments truly more secure than accessing pserver over an ssh tunnel? Yes, I know you can do both. There was some talk o
That's why you would tunnel it over ssh or something like that, with limited key access. People you trust get the key, and their key gets kept on the server. Definitely, a wide-open pserver connectio
The repository is likely to be one of the more valuable things the enterprise has on its computers, and so fencing everything else off from it may not make sense. In general, I like the idea of usin
Note that giving anyone pserver access to a machine is equivalent to giving them local shell access -- there are fairly simple tricks that can be used to execute arbitrary code on the server. CVS was
[ On Monday, December 16, 2002 at 17:16:41 (+0100), Walter, Jan wrote: ] No, that's why you'd use SSH plain and simple with real, proper, unique system accounts for every real person, and never use C
CHARLES HART, BLOOMBERG/ 499 PARK wrote: um, I'm a newbie at CVS, so I've read more of the documentation than anything else, but the answers I've seen so far for the security question seem to have mi
SSH (at least SSH2) can be configured in such a way that only CVS can be executed with a particular key pair. I think this means that one would need to subvert CVS or SSH in order to manipulate the i
um, I'm a newbie at CVS, so I've read more of the documentation than anything else, but the answers I've seen so far for the security question seem to have missed one vital point. People have write a
Yes, this you are correct... chrooting a file system would have no impact on the user's ability to access the repository. The best method for keeping folks out is to use public key ssh auth, constra
The advantage to chroot environments is that they can limit exposure to things like rogue *info scripts that might reach beyond the CVS repository. This is handy in the event that you store sensitive
No, pserver passwords are not encrypted with a strong algorithm. In fact it is extremely weak - a simple substitution table. Try using the :ext: access methon with ssh. Derek -- Derek Price CVS Solut
I see. I guess it's obvious that the repository would have to be within the chroot'ed environment meaning that such an environment wouldn't help in preventing users from directly accessing the archiv
I would be astonished if this were true. You'd have to replicate /bin, /usr/bin, /etc, /lib, /usr/lib, /etc, /usr/local, /include, /usr/include, /dev, and a whole lot of other stuff to make it work a
Oh, but that's OK - just set the shells for the users to /bin/false - that'll prevent them from logging in with a shell. And isn't there a way to specify a chrooted home directory in /etc/passwd? Can
A chroot environment is only good at containing what's inside it. It does not prevent access to the chroot environment from outside. In other words, chroot is fine for containing servers so that they
This is not necessarily true, as you can use CVS within a chroot'ed environment. In that case you can prevent your users from getting a shell resp. from executing any commands than the few you allow
NO Use the :ext: method in conjunction with CVS_RSH=`which ssh`. And yes, this has been discussed a thousand times already. See the archives for more details. Or visit sourcefourge for their setup in
Dear all, please excuse my -- potentially -- missleading subject if applicable. Question: - Are the passwords and the contents encrypted with a strong algorithm in case a remote repository is accesse