Re: CVS secure shell?
Infoman: Martin Kretschmar wrote: > > Well, this looks like a FAQ. But searching the site for > "secure shell" wasn't 100% rewarding. With a search to > "restricted cvs shell" google brought up several items. > Specifically the CVSH looks as if it was what we would > like to have. > > For e.g. disallowing logins via SSH combined with a "rm" > of specific files inside the repository it would be nice > to have a shell which accepts only cvs command and maybe > exit. This would be added to the family of the available > shells. > > Further informations would be welcome. > I suggest you check http://www.idealx.org/prj/idx-chrooted-ssh-cvs/index.en.html which describes how to setup a CVS server with maximum security using SSH and chroot. Hope this helps. -- Olivier BERGER IDEALX S.A.S. Développeur senior 15-17, av. de Ségur 01.44.42.00.00 F-75007 PARIS 06.81.27.86.79 http://IDEALX.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Chrooted SSH CVS server HOW-TO - DRAFT version - R20010423
Hello, fellow CVS administrators. I'd like to announce the availability (first public release, on http://www.idealx.org) of a new HOW-TO published under the GNU FDL. This document describes the steps necessary to setup a very network-secure CVS server, allowing SSH access to chrooted CVS repositories. Using this strategy, it is possible to have multiple repositories on the same server, each one in its own protected directory tree (chrooted), and with respective access privileges thanks to SSH. The use of SSH (with CVS_RSH) as a transport mechanism for CVS (instead of having a CVS pserver and SSH tunneling between client and server) allows much more secure and flexible use on the client side (provided SSH is installed, of course). The shell accounts necessary for SSH to run are disabled in order to allow only remote access to CVS. Both read-only (and even anonymous, i.e. with a known password or even no password at all) and read-write access can be granted, depending on the user accounts. The HOWTO's package, release R20010423 (including DocBook source for the HOWTO, small scripts (alpha stage) and necessary source code) can be found from http://www.idealx.org/prj/idx-chrooted-ssh-cvs/index.en.html For those wishing to consult the howto in HTML form, please go to : http://www.idealx.org/prj/idx-chrooted-ssh-cvs/dist/chrooted-ssh-cvs-server.html Standard disclaimer : The elements described in this HOW-TO have been tested in order to ensure maximum safety. But as usual, we cannot guaranty that every aspects were sufficiently examined or tested. YOU MAY FOLLOW THE GUIDELINES AND USE THE TOOLS DESCRIBED HERE ONLY AT YOUR OWN RISK. Neither the authors nor their company should be liaible for any loss of data or other potential damage resulting from using the methods or tools described here. Due to the risks of misconfiguration resulting from the various manuel configuration steps necessary to setup such a server, we recommand that you carefully test your installation before connecting the server to the Internet and let user store their data in the CVS repositories. I welcome any comments regarding this Document and associate tools, and would be happy to get feedback if you found it useful in order to setup your own CVS server. Best regards. -- Olivier BERGER IDEALX S.A.S. Développeur senior 15-17, av. de Ségur 01.44.42.00.00 F-75007 PARIS 06.81.27.86.79 http://IDEALX.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs remote: rsh vs. ssh protocols
[EMAIL PROTECTED] a écrit : > > We have tried every conceivable modifications of permissions but have > come to the conclusion that instituting 'ssh' is preventing us from > utilizing rsh completely as is needed for CVS to work between > machines. > Do we now need to use 'ssh' as the protocol for CVS updates? If so, > what would be the best way to implement this? I saw an earlier thread > that described this somewhat but haven't had luck in getting the two > machines to communicate yet. I'm not sure I understand your problem... as it seems to me that you may misunderstand the role of ssh in the process of using CVS with CVS_RSH=ssh. I could draw cvs' use of SSH as follows : the developper on the client machine issues a "cvs checkout -c" command (for instance) : the "cvs" command on the client machine spawns a "ssh login@servermachine cvs server" if login@servermachine is in the CVSROOT definition (for instance CVSROOT=login@servermachine:/usr/local/cvs_repo and CVS_RSH=ssh). Next, on the server, if your user "login" is configured with a valid shell account with, say, bash login-shell (and of course a valid "$HOME/.ssh" directory/ssh-configuration, and all the stuff needed for a successfull login on the server), the sshd daemon on the server will run "bash -c cvs server". That will hopefully launch the "cvs" command on the server (with arg "server"), and from that point, the cvs commands on client and server will talk through the I/O channels that ssh provides, and in a secure way. All you need for this to succeed, is a valid "login" account on the server, and the ability to execute remotely the command "ssh servermachine -l login cvs server" from your client. You may try this without any risk to check that everything works fine. If it does (you get stuck talking to the cvs command on the server (try to type anything then C-c C-d and should see some messages of the CVS protocol... a bit like talking to smtp or pop daemons trough telnet)), then evrything should work fine for CVS... If it doesn't (error message from ssh, wrong password, network problems, permissions or authetication problems, etc.) then you'd better solve this first. Now, some more diagnostic may be found by using ssh verbose messages (RTFM) to debug the remote execution process. Hope this helps. -- Olivier BERGER IDEALX S.A.S. Développeur senior 15-17, av. de Ségur 01.44.42.00.00 F-75007 PARIS 06.81.27.86.79 http://IDEALX.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: ssl redux
Dan Kegel a écrit : > > I need encrypted sessions, but don't want to give shell > accounts to my cvs users. > This might no suit exactly your needs, but fyi, check the following page : http://www.kitenet.net/programs/sshcvs/ -- Olivier BERGER IDEALX S.A.S. Développeur senior 15-17, av. de Ségur 01.44.42.00.00 F-75007 PARIS 06.81.27.86.79 http://IDEALX.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs commit confusing behaviour on modified files without changed content
Hi. I'd like to report some kind of confusing behaviour about cvs commit, and see what you folks think about (bug ?). Let's say that I have a checked out file, that I edit, changing it's content, and about which I later changed my mind, removing the changes. The content gets back to the initial state, even if the modification date of the file has changed. If i issue a cvs commit command, cvs will ask for a commit log message, displaying a pre-filled editor with the file marked as modified. But as I save the message and exit the editor, nothing gets committed. As cvs has connected to the server, it detects that the content hasn't changed, and doesn't commit anything without notifying me. So everything looks like the commit aborted for some unreported reason. What do you think about that (client 1.10.7 - server 1.10.6) ? -- Olivier BERGER IDEALX S.A.S. Développeur senior 15-17, av. de Ségur 01.44.42.00.00 F-75007 PARIS 06.81.27.86.79 http://IDEALX.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Is val-tags automatically created
I wonder when the CVSROOT/val-tags file gets created. At the present time, I have a repository with no val-tags file (default when created from cvs init ?), and I can successfully create tags (even branch tags) on my elements. No val-tags gets created when I create the tags. Although the documentation seems very poor about that file, I thought (from reading various discussions) that it was created by cvs. So when ? What happens if I write protect my CVSROOT directory ? ... May it cause some problems with later val-tag creation attempts ? Thanx in advance. -- Olivier BERGER IDEALX S.A.S. Développeur senior 15-17, av. de Ségur 01.44.42.00.00 F-75007 PARIS 06.81.27.86.79 http://IDEALX.com/
Securing CVSROOT write access with LockDir
Hi. We're currently using CVS 1.10 on GNU/Linux platform, with ssh as CVS_RSH connection method. Our repository contains a rwxrwsr-x CVSROOT directory, in order to let everybody create lock files (every developper belongs to the group owning CVSROOT). This is problematic since we don't want everybody to be able to commit changes into CVSROOT , which is possible with the current right of CVSROOT : even if we write-protect individual files in CVSROOT, there are nevertheless changed (deleted/re-created ?) after a user has commited them. We plan to use the LockDir option of CVSROOT/config to have locks created in a different directory than CVSROOT. Then we can write-protect CVSROOT and make it, for instance rwxr-xr-x, which prevents anybody but the owner to commit any modifications to it. I have several questions though : - is this a good way to secure the CVS system (ssh handles privileges, then individual repository directories use unix groups for protection, and CVSROOT can only be modified by the admin) ? - which files have to remain writable inside CVSROOT (thinking to history, val-tags) ? - what exact compatibility problems exist between V1.9/V1.10 of CVS about this LockDir option (the documentation is not very clear as if it is a problem with CVS clients versions, or migrating the repository to a downgraded server version, etc.) ? Btw, I have been poorly lucky when looking for information about securing the repository, and found very few details about this way of protecting CVSROOT. I think that it may be because many people use CVS with pserver, but anyway, I suggest that maintainers of CVS documentation / sites add a detailed section on this security problem / solution, if it is the right one ;)... Thanx in advance for your help. -- Olivier BERGER IDEALX S.A.S. Développeur senior 15-17, av. de Ségur 01.44.42.00.00 F-75007 PARIS 06.81.27.86.79 http://IDEALX.com/
