If you want you can skip the beginning blurb and go right to the recipe.
Every so often you face a tough problem then someone sayz to yuh, “Cliff, have you tried ssh tunnels?” (well that’s what hey would say to you if you were me, and if you were me you would have a habit of making easy problems way tougher than they need to be while you make tough problems easy.) That’s what happened to me a loooong time ago… like around last month. The I was chattin’ with the VP of technology about all things Maven and mobile related explaining how clever we were with our solution to on device testing when he suggested we try ssh tunneling. I read an article that day and got excited because it looked soo easy. Then I made a promise to our mobile dev team that I would prototype it over the weeken. Then I quietly forgot about it. Today the question came up again and I was like, “Oh crap! I never did try prototyping a solution to that problem!” I gave it a good hour of effort before getting stuck. It’s really not that difficult, and after leaving for the day, coming home and attacking it fresh I found that I only had one minor problem… I didn’t read the docs completely. (That’s how it goes when I see something cool. I jump in head first and complain because I always miss something simple and fundamental.) Silly babbling aside I present you the how to on what to do to get to your CPU thru EC2…
(or any other public remote web host)
1 Remote server running a flavor of ssh. (In my example I assume openSSH as it’s prevalent across many Linux distros.)
1 local computer that you desire to access also running a flavor of ssh (I’m using OS X in my example.)
2 Eggs slightly beaten whites removed.
1. Combine one additional parameter with the default sshd_config file under our server’s /etc/ssh folder. Use vi, nano, kate, gedit or a fancy command like the following.
sudo echo ” GatewayPorts yes” >> /etc/ssh/sshd_config
[For best results supply password when using the above crazy command.] The parameter name is GatewayPorts and the value should be yes to allow clients other than the server itself to tunnel into your local machine.
2. Execute one sshd restart command to allow the new parameter to be considered on the server. Eg.
sudo /etc/sshd restart
3. Add -R [remote port]:localhost:[local port] to 1 1/2 cup of ssh command typing slow to avoid error. The remote port is the port number you wish to tunnel through on the remote machine while the local port is the port you want all traffic to be directed to on the local machine. Eg.
ssh me@myremotehost -R 80:localhost:9002
This can be used to forward all web server requests to a server app running on the crappy Compaq that you used to execute the ssh command.
That’s it! The net result would be a service running on your desktop/laptop/MacBook in your garage appearing as if was running on the public remote web host. So then you point your browser to http://myremotehost and your home equipment gets all the traffic. The secret is the “GatewayPorts yes” property that must be set in the remote host’s /etc/ssh/sshd_config file. That secret value bypasses all common sense security allowing anybody on the internet to peek into your home located machine and access the pictures of you and the kids looking burnt up at Daytona Beach, FL.
Now why would you want to do that? There are all sorts of possibilities that arise when you start playing with tunnels. First off, they run through the security of secure shell, a robust tool that I’ve only begun to understand the capabilities of. (It seems like ssh can do everything from being a secure channel, to enabling sFTP, to being a mountable file system allowing Windows explorer like file browsing, to recording those 10:30am episodes of Judge Judy while you’re at work. Yes, ssh can do that too.) Tunnels work both ways, remote forwarding and local forwarding. If you were behind a firewall that allowed connections to remote ssh hosts but blocked some other port/protocol you could sidestep by doing something similar to the above but substituting the ‘-R’ with a ‘-L’ for a local forward. Then all the traffic sent to the machine you run the ssh command from would be forwarded to the remote host. It’s so simple! Setting up a tunnel is a matter of specifying the port you want to forward from and the port you want to forward to! Use your imagination, and happy port forwarding!