bert
[Entry]
"Having had trouble with innaM's answer, even though it is spot on, and not repeated here, perhaps some additional information could help the odd user having trouble implementing the answer.
In the case of difficulty, be sure to experiment with the ssh and cvs commands on the command-line before going to the point of adding the configuration for the LocalForward in the config file. Editing the config file early can be discouraging if anything about a particular setup is slightly different than the answerer's environment.
One of the first problems one can encounter is rare, but crucial. It is of paramount importance to know the correct location of the config file. In most cases, the correct location is ~/.ssh/config / ${HOME}/.ssh/config, but, sometimes it is not. The correct config file location is required to solve this problem even when experimenting from a command-line. See also: ssh is no longer using ~/.ssh/config
There is also the potential of running afoul of permissions issues. It is usually safe during troubleshooting to set both the .ssh folder and the config file read-only for the user (i.e. chmod 600) though it is not necessarily required that the permissions are quite this tight. In any event, the folder and file should not be writable by other users.
There is also the matter of setting CVS_RSH properly. Even if the ssh environment is set up properly, the final cvs command will fail with a very unhelpful message if CVS_RSH is not properly prepared.
CVS_RSH=ssh; export CVS_RSH
Without CVS_RSH, the cvs command is likely to return:
-l: bad option(s)
cvs [... aborted]: end of file from server (consult above messages if any)
It is not necessary to have two shells open to work with the tunnel. innaM's answer says to set up the tunnel with:
ssh B
This leaves you with a shell open on B, and not on the local workstation. It is not necessary to have a shell open on B. One can work entirely within a single shell by setting up the tunnel with:
ssh -fN B
This command leaves you at the local system prompt rather than at a B prompt. The caveat is that in the case of ssh B it is possible to tear down the forwarding by simply logging off of B, whereas in the case of ssh -fN B the ssh process is in the background and must be killed by other means to tear down the forwarder.
When multiple systems require alternate port numbers, adding a Port option to the applicable config Host section is viable.
Bear in mind that the config file may specify User in Host sections when user names vary from system to system.
Another potential pitfall may occur in cases where user names are improperly specified. While it is often correct and proper to specify system user names as user@hostname, DO NOT use this notation in the config file or in the ssh -L parameter. For example, this will go horribly wrong and may be very difficult to unravel:
ssh -L 2200:Auser@A:22 Buser@B
(This is never necessary CVS usage since Auser@ is specified with cvs -d :ext:Auser@A:/path/to/repository.)
While is it perfectly acceptable to specify Buser@B, Auser@ must not be specified this way on either a command-line or in the config file. A cvs command issue with an incorrect command like this may return something like:
ssh_exchange_identification: read: Connection reset by peer
cvs [checkout aborted]: end of file from server (consult above messages if any)
Debugging can be difficult, and can result in other inexplicable messages like:
SSH Tunnel: channel 3: open failed: administratively prohibited
The problem is that when used with -L or LocalForward, Auser@ becomes part of the host name (or IP address) so it does not resolve to the expected IP address."
|
