This command is equivalent to the example given on that page:
ssh myuserid@gate -L 7777:work:22 cat -
Now for some clarification of this weird but effective syntax:
1. Traffic on port 7777 on your local machine goes to "gate" via the ordinary ssh port. "gate" forwards this traffic on to port 22 on "work".
As port 7777 is a local port, you can choose this to be pretty much anything from 1024 onwards and don't have to reconfigure your firewall.
You can change port 22 (ssh) to e.g. http to access the web server on "work" as if you were sitting at "gate". Now access http://localhost:7777/!
2. The name lookup for "work" occurs on "gate", not your local machine. This is very useful.
3. The "cat -" is a hack to keep the tunnel open.
I'm no network guru and have been wanting to learn this for ages but only found explanations that go on for pages about how great ssh forwarding is without actually giving a straightforward example. Others were obsessed with the intricacies of command line options.
For these reasons and because I don't have time to read a tutorial longer than documents I give to lawyers, I still have no idea how to write iptables rules by hand. If all documentation was like that we would all be spending most of our lives reading instead using computers. Hardly, a "simple primer" as claimed. So when I find a simple tutorial about iptables, I'll blog it.
5 comments:
you can also do this in reverse i.e. bring a port on your local machine to the remote machine when you ssh onto that machine ( this may be useful when you have SVN on your local machine but it is not available on the remote machine). The -R parameter is used for that.
instead of using a command that waits forever like `cat -` you can give the -N option to ssh, which prevents it from executing a remote command.
And besides the -N option mentioned by the previous poster, if you're behind a router that kills idle connections you can force activity by adding a line like
host foo.bar.com
ServerAliveInterval 60
to ~/.ssh/config.
Also, if you want more dynamic port forwarding, be sure to check the -D option. This turns the SSH client into a SOCKS proxy, against which you can talk with socks-capable software (or use socksify to preload a wrapper library).
Yeah, I discovered tunnelling also lately (later than the average geek of my age).
I use it to encrypt VNC connections, which are not encrypted on default. I was happy to finally fiddled that out, so I wrote a little article about it:
http://www.xs4all.nl/~schoenb/linux/vncssh.html
As long FreeNX is still choking, I can now securely connect to my desktop.
Cool stuff - thanks for the hints guys!
Post a Comment