SSH Tunnels How-to?

The_Spider asks: "I periodically browse the net and check web-mail at work, when I have the opportunity. I was wondering if anyone had a nice walkthrough on how to set-up an SSH tunnel. I'm not 100% newbish to Linux but I don't know where to start. (I have a Fedora Core box at home for NAT & DHCP) I'm hoping to combine this for use with portable Firefox. I'm not to worried about security, but I love the notion of taking a portable and encrypted browser with me from place to place. Can Slashdot help?" While this might be a bit FAQ, I figure Slashdot anecdotes on the use of SSH tunnels might be a bit more user-friendly than say, the several task-specific HOWTOs one can find via a Google search. ALso, I'm sure that there are a few of you out there who have discovered interesting ways of using SSH tunnels, not covered by said HOWTOs. So, how are you using SSH tunnels, and can you explain them to those who have not yet discovered the value of their use?

Comments

Java VNC over SSH

[slthytove]

This doesn't really address the author's original inquiry, but it is (what I would consider) an interesting use of SSH tunnels, in a readable tutorial. I set up something similar to "GoToMyPC" for my Dad, that allows web-based (over JavaVNC) secure remote access to his computers:

Java VNC over SSH

Just what you are looking for...

[linuxkrn]

Got one of those on my website.

Enjoy http://www.linuxlogin.com/linux/admin/sshtunnels.p hp

Try the HowTo...

[Anonymous Cumshot]

here: http://www.revsys.com/writings/quicktips/ssh-tunne l.html

It's nice and short, but covers the basics.

Gotta love SSH tunneling

[The Blue Meanie]

I *really* hope my employer doesn't recognize my Slashdot ID. :)

I use an SSH tunnel to forward port 8080 on my desktop machine here at work to port 8080 on my Unix workstation at home that's running an HTTP proxy. I set my Firefox/Mozilla at work to use localhost as its proxy, and I now happily bypass any and all logging and/or site restrictions on my work browsing habits.

I also remote-forward a pseudo-random high port on that remote workstation at home to port 22 on my work desktop machine, giving me the ability to SSH *back in* to work from home, and not monkey with the company's VPN solution that has a client for my home machine that's so buggy it's unreal. That remote SSH call-back also forwards the home machine's IMAP port to the company's Exchange Server so I can read my email over the tunnel, and I port-forward to our network monitoring and backup systems' web interfaces so I can actually do my job.

I guess I can say that my productivity from home would be pretty much zippo if I didn't have SSH tunnels at my disposal.

Re:Gotta love SSH tunneling

[fimbulvetr]

This is exactly what I do, and let me tell you what: It's saved my ass a few times.

I also run two browser profiles with one being the proxied and one being normal, with different shortcuts to each. I separate the instances so my employer still sees a lot of traffic so they don't get suspicious. The work-related ones get me to lots of vendors sites, googling for solutions, etc.

I use a sh script to start my second one. It looks for an already open port just in case I killed the browser accidently and don't need to re-establish the tunnel. It re-establishes if it needs to.

You could also proxy your IM messages through these, though I haven't gone to that length yet. Here's my sh script:

#!/bin/sh

STAT=`netstat -an | grep 8888`;
if [ "$STAT" = "" ];
                then

#friendshomemachine
# ssh -L 8888:127.0.0.1:8888 friendshomemachine "perl -e 'while (1) { print localtime."\n";sleep 10;}'" &
#mine
                ssh -L 8888:127.0.0.1:8888 myhomemachine "perl -e 'while (1) { print localtime."\n";sleep 10;}'" &
#friendshomemachine
# ssh -c blowfish-cbc -C -f -N -L 8888:127.0.0.1:8888 friendshomemachine "perl -e 'while (1) { print localtime."\n";sleep 10;}'" &
#mward
# ssh -c blowfish-cbc -C -f -N -L 8888:127.0.0.1:8888 friendshomemachine "perl -e 'while (1) { print localtime."\n";sleep 10;}'" &

fi /usr/local/firefox/firefox -P encrypted

I've heard blowfish is slower, but it doesn't seem to be when you're just browsing. Feel free to experiment. Others with more knowledge as to what's faster, please let me know.

Re:Gotta love SSH tunneling

[Dausha]

"I *really* hope my employer doesn't recognize my Slashdot ID."

Yes, your employer does know your uid. He's pissed, and he's been logging your activity for some time. He suggests a new shell script:

#!/bin/sh

while (1) {
echo "Get to work, Slacker!";
}

Here's one...

[Anonymous Coward]

1. Set up usual SSH session settings in Putty
2. Go to Connection -> SSH -> Tunnels
3. Add new forwarded port. Source Port: 1080, Destination: [blank], DYNAMIC (this is important), Auto. Click on Add.
4. In Firefox or any other program that supports a SOCKS proxy, enter host 127.0.0.1 (localhost) with port 1080.

That's it. You'll then be using your SSH connection like a SOCKS proxy.

Re:Here's one...

[spectral]

normal ssh forwards are one-source, one-destination. There are options to allow the entrypoint to the tunnel to come from !localhost, (i.e. I set up an ssh connection from me to my friend, with a tunnel from me to google.com, and now anyone who can connect to me can use that same tunnel to connect to google.com), but normally it really is a one-off thing.

127.0.0.1:1000 goes to www.google.com:80
127.0.0.1:1001 goes to www.porn.com:80
127.0.0.1:1002 goes to www.slashdot.org:80

what using a SOCKS-mimicing "proxy server" allows you to do is to make it so that the requesting application requests the destination, instead of you setting it up and then pointing your computer at a special address. The requesting socks-aware application is like "Hmm, to get to login.messenger.yahoo.com:3697, I must use this special protocol and send stuff really to a connection at 127.0.0.1:4280. I'll do that."

So it connects to that, PuTTY sends it down the wire to my friend, and my friend's computer sends it to login.messenger.yahoo.com, port 3697.

magically. :)

Here's mine

[Dadoo]

We use this actual script (plus a few things I had to edit out for anonymity's sake).

Assuming a Linux machine at each end, here's the script for the machine that initiates the connection:

        while true; do
                pppd nodetach lcp-echo-failure 4 lcp-echo-interval 120 \
                        pty 'ssh receiver -T -l user'
                sleep 10
        done

Where receiver is the public IP address of your receiving machine and user is the username on that machine. The while loop automatically reconnects if you get disconnected.

Here's the script for the machine that receives the connection:

        pids=`ps -e -opid,command | grep "pppd local:remote" | \
                grep -v grep | awk '{print $1}'`

        if [ "$pids" != "" ]; then
                echo "Found pre-existing connection. Killing pids: $pids" >> ppp.log
                kill -15 $pids
                sleep 5
        fi

        pppd local:remote netmask 255.255.255.252 passive \
                notty nodetach

Where local is the local end of your PPP link and remote is the remote end of your PPP link. You'll want to call this script from user's .profile. Remember, this is a private link, so you'll probably want local and remote to be internal addresses, i.e. 192.168.x.x.

Really Good SSH Tunneling Tutorial

[cyranoVR]

http://souptonuts.sourceforge.net/sshtips.htm

Really good for the beginner - includes information on accessing Samba shares over ssh.

The only way to do work

[Fred Nerk]

I work in a large telco who's security policy is to restrict everything unless explicitly allowed, and the process to get anything allowed is a 3 month long waste of time.

I also have an ssh tunnel established from my work PC to my home connection, and I run pppd over that to create a VPN between my home network and the network at work. I realise that this is probably completely against company policy, but the "official" VPN solution only lets me hit the Exchange server, and doesn't let me actually do any work. Most of the company's "work" involves forwarding emails, so it's probably fine for them.

Unfortunately tcp over tcp is really quite nasty (http://sites.inka.de/sites/bigred/devel/tcp-tcp.h tml) but as nothing else but ssh is allowed out of the firewall at work, I don't have a lot of choice.

A howto that I found quite helpful is at http://www.tldp.org/HOWTO/ppp-ssh/

Anyway.. on to my anecdote (not required reading):

Part of my job involves working on a distributed monitoring system which is deployed in a star topography around the country. All the remote sites send & receive data from one central site (with one redundant central site) using a variety of protocols, like ssh, xmlrpc, dns, telnet, snmp, syslog, etc.

The network was designed by people who were given a set of instructions like "You will use these 2 vendor's systems" and "You must follow these corporate security policies which were written 10 years ago for phone networks", so it's terrible by today's standards (and for an ISP in general).

There are firewalls between all of my boxes, even though all my boxes are on the management lan, and they only allow a very small set of protocols through - not enough to let my software work. That wasn't the worst part. The worst was that the firewalls are also protecting the billing network so have very low tolerances for intrusion detection and flood protection and such. Basically I can only establish 5 connections per second *across the entire network*. This is clearly not enough for a busy monitoring system. So we decided to build a VPN between all of my boxes using ppp on ssh tunnels.

I now have a separate ppp interface from the central server to each of the remote datacenter servers, all on the 10.0.0.0/16 network. ip forwarding is enabled on the central site, so now remote datacenters can talk to each other (also blocked by the firewalls) and I can use all the connections I need to. I'm running quagga ( http://www.quagga.net/ ) on every remote datacenter and the central servers (along with the redundant one) so I can distribute routes to remote datacenter devices and cope with the death of one of the central servers without major service interruption.

However it really is quite slow. I can only get around 200kb/s over each ppp interface even though the physical links are 100+mbit each. But I really don't need huge bandwidth, just some that isn't firewalled.

This "solution" has been in production for 6 months now, and I'm sure as soon as the corporate security people find out they will shut it down and I'll go back to not being able to do my job.