Deron Meranda wrote: > On 6/29/05, Dan Trainor <info@xxxxxxxxxxxxxxxx> wrote: > >>From what I understand by reading the man page, is that I can make an >>ssh connection to a remote machine, using the -R switch, which opens a >>port on the remote machine, which is then redirected to the local >>machine, on a port of my choosing. >> >>So naturally, I'd like to do something like this - from the client: >> >>ssh -l username -R 22:localhost:10002 remotehost >> >>I am able to log in to remotehost. I've even used root as the username >>just for kicks, but I am then presented with the following error regardless: >> >>Warning: remote port forwarding failed for listen on port 22 > > > You probably want -R 10002:localhost:22 instead. > > The first number is the number of the port on the REMOTE host > (the one you're logging into) which will be opened in a LISTEN > state. The last number is the port on "localhost" to which the > connection will be tunneled. > > I've done this a lot and it works, but it's not entirely robust. > You may want to enable the keepalive packets, otherwise an > idle connection may be dropped by any firewalls between > your two boxes. Also if you pick a high port like 10002 there > is a small chance that at any given time that port may be in > use, and the port forward will fail. If all you're wanting to do is > the reverse tunnel, you may also want to use the switches: -n -N -f > > I also usually put the ssh comman inside a shell script with > a while loop, so if the ssh connection is ever dropped for > some reason it will automatically re-establish. You'll definitely > want to be using RSA keys and an ssh agent. This makes it > all more secure, plus keeps the password prompts from > appearing. > > Also, don't expect the world's best performance. Nesting > tunnels like this has a lot of overhead...especially when > using a TCP-based tunnel (ssh) rather than UDP (like L2TP). Derom - Thanks for the response. I figured out the problem shortly after I sent the email out - you are correct. I will be using RSA keys to accomplish this, since the tunnel would be an automated process. I don't think I have to worry too much about the remote port being in use, except in extreme cases. However, this will be taken into consideration. I don't expect any sort of good performance. I merely would like to have access to a machine behind a plethora of networking hardware, for remote management. I know that this is not an optimal solution, but for the short run, it works well. Thanks again! -dant
