[HOWTO] - SSH Tunneling for Mac Users

[michaelsanford]

There are a few great FAQs and HOW-TOs on this, but I figured we deserved our own.

What is SSH tunneling and what's it good for?
SSH (secure socket shell) is an encrypted connection between two computers that allows not only a secure remote terminal session but encrypted data transfer as well.

An SSH tunnel is simply one or more parallel data stream that get built when you connect to a remote host. Through this tunnel you can securely access any open service on the remote machine, from FTP to AFP to VNC to printing, and let's not forget X11!

How does it work?
Basically when you connect via `ssh` to a remote host, you specify some extra command line arguments that tell ssh something like "get the remote hosts's AFP port (548) to forward to my local port 10548 over the secure channel". This is called a direct port forward.

With this clever tool you can also forward any port on any machine that the remote machine is connected to, to your local machine over the secure channel, like "Tell the remote machine to connect to my router's web interface and forward that over the secure connection to my local port 10080".

The Syntax
Let's look at the following line:
ssh myhost.local -c blowfish -X -L 10548:127.0.0.1:548 -L 10080:192.168.0.0:88

The first part tells ssh to connect to myhost.local.

The red part tells ssh "Connect to 127.0.0.1 (localhost) at my port 10548, and route it to myhost.local's port 548". Then when you want to access myhost.local's AFP, you choose Connect To from the Finder and enter 127.0.0.1:10548 and voilà, up pops a connection dialogue for myhost.local.

The blue part tells ssh "Connect to 192.168.0.0 port 88 on the LAN to which myhost.local is connected, and forward that to my local port 10080". This is useful when you have a router with a web-based interface and don't want to open it up to the WAN, you can use this method to connect to it. You then enter http://127.0.0.1:10080 in Safari and voilà up pops the web interface for myhost.local's router.

If you want to enable X11 forwarding, you need to add the -X command-line flag, but you don't have to enter any host or port information, -X will automatically forward remote X11 sessions to your local machine. You must use an X11-based terminal program to create the tunnel however, or else the $DISPLAY variable won't be set and your local X11 won't know where the display is.

Tips for better operation
1. Use a 'shabbier' cypher. By default ssh will use 3des (triple-des) which is an encrypt-decrypt-encrypt triple algorythm with three different keys. As you can imagine for the text of a terminal session it makes little difference, but for AFP for VNC/X11 it will slow the connection immensely on a slow computer. Specify the blowfish algorythm using -c blowfish which is secure, and faster. If however you're extremely paranoid about security and have a very fast computer, des or 3des should work all right.

2. Once you connect to the remote machine renice the thread called AppleFileServer (AppleFileS) to something negative. If you have a slow system and have other apps running this may give you a tiny edge on file sharing.

3. Always, always end your tunneled sessions with ~& instead of logout or ^D. This is an escape character that tells ssh to background itself until all the secured channels are closed.

This means that you can exit the terminal and leave your AFP volumes mounted, then when you unmount them the SSH session closes completely. If, on the other hand, you choose ^D or logout, your drives won't be softly unmounted, they'll be ripped out and nobody wants that.

Note however that only persistent services (like AFP) will remain open after a background escape (~&) is issued, services like HTTP tunnels (like the router's web interface) will close as soon as the page is loaded (i.e., immediately if no page is loading).

[dlloyd]

So technically if I'm behind a firewall that doesn't allow me to use, for example, the right port for the Apache webhost, if I had access to another computer outside of the firewall, I could use that IP address and have it forward the appropriate ports to my computer, and thus set up a 'proxy' type thing?

[rhg]

@michael: Thank you for this great HOWTO.

@dlloyd: That's correct, as long as you can reach the system you specify in the -L expression from the system you ssh to.

[dlloyd]

Hmmm, that would be really cool .

[rhg]

For example, the e-mail server in the internal network is at 111.222.24.25. It is, however, not reachable via ssh because by purpose it doesn't have a default route. The firewall will only let ssh pass through to the 111.222.24.77 machine. If I want to access my company e-mail from home I would do:

ssh -C 111.222.24.77 -L143:111.222.24.25:143

After that I simply connect my IMAP e-mail client to localhost (port 143 is IMAP2) which goes through the ssh tunnel behind the scenes and connects to 111.222.24.25 on port 143. The -C option compresses all the traffic so the tunnel is even faster than plain IMAP

[dlloyd]

Wow, sounds REALLY cool!

[scruffy]

Perhaps you have a suggestion for this - I'm trying to do essentially the same as X11 forwarding, but in the opposite direction. The school firewalls allow no incoming connections, so I send out a ssh connection to my home computer, and forward telnet back along it to the school one, with
ssh -R 2323:127.0.0.1:23 scruffy@scruffys.comp
I get home, telnet localhost 2323, works like a charm.

What I can't seem to do is send X11 connections back to my home computer. I've tried adding
-L 6010:127.0.0.1:6000
Then I telnet back to the shool machine (with X11 running at home), set the display to ":10", but still can't launch any X11 apps.

I know, I could forward inbound ssh over the outbound ssh channel, and
ssh -p 2222 -X localhost
or whatever, but I'd like to avoid encrypting everything twice. The nice 2GHz P4 at school could handle it fine, but my poor 300 MHz G3 would be running pretty hot trying to double-encrypt all the X11 traffic...

Incidentally, you can also add the '-fN' flags, which will send ssh to the background immediately after authenticating, and the connection will be persistent. Actually not entirely persistent, it can still timeout - this was a problem for me, since the connection had to survive hours and hours of idle time till I wanted to telnet back. I had to download a patch for openSSH that adds a heartbeat - it sends a special ssh 'null' packet every so often to keep the connection going.

[scruffy]

Oh, another tip for performance - if you have a slow connection, and the computers at either end are reasonably fast, you can add the -z flag to compress the traffic with gzip. That way if you're going to be using stuff that generates a lot of traffic, like X11 or file transfers, you can trade some of the connection load for extra CPU load.