Re: cvs remote: rsh vs. ssh protocols

[Olivier Berger]

address@hidden 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
address@hidden cvs server" if address@hidden is in the CVSROOT
definition (for instance address@hidden:/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/