Tips August 16, 2004 at 9:17 am

The Light at the End of the SSH Tunnel

Stuck behind a draconian firewall and you need access to your Mac OS X Server? Read on to find out about the only tunnel on your Mac where you are not likely to be eaten by a grue…

(Updated 8/16/2004, 2:03 PM EST)The Problem

As some of you might, know I have been contracted (pimped?) out to a Fortune 50 company for a few months. Understandably the network here is locked down pretty tight. I can get IMAP mail from, but not send via SMTP to my Mac OS X Servers and I can’t access our Filemaker Pro databases either. Now I can, and was, use WebMail on our server but I would rather just use regular old Apple Mail where I keep local caches of things like the Mac OS X Server mailing list. Otherwise I have to copy all those messages when I get home to my local folders. It isn’t a hard task, but it is something extra to do.

At first I tried to connect to our VPN server, but both L2PT and PPTP are blocked as well. Enter the SSH tunnel…

Digging a hole to China

Since I have SSH access to my servers, I can use that access to gain access to the services I need on the outside of the firewall. As an added benefit any traffic that I pass through my tunnel is encrypted as well. Think of it as a poor man’s VPN. Here’s how it works:

Using my SSH access to a server outside the firewall I can setup a tunnel that directs a local TCP port to something else on the other end. If it is a service that runs on a privileged port like 25 then we can direct a high number local port to emerge as the privileged port on the other end. In this example we are going to turn local 1025 into 25 on the other end as well as map the local high port that Filemaker uses to the appropriate host on the other end.

Introducing the new, easily imitated, AFP548 command-o-matic!
(Remember, the final command should be all on one line.)

I’m going to show you how to build the command one step at a time. These are not individual steps, rather I am explaining each part of the command as we go along.
So fire up the Terminal and join in the fun!

First we need to start up SSH and tell it what user to login as,

ssh -l josh

next tell it we are going to map a local port, in this case 1025,

ssh -l josh -L 1025:

to a remote port on remote target, here port 25 on my mail server,

ssh -l josh -L

in my case I also want to use Filemaker Pro so I need a second mapping,

ssh -l josh -L -L

and finally I need to tell it what server I have an SSH account on. Your complete command should look something like this:

ssh -l josh -L -L

Notice that it is the same as my FMP server, that’s fine. Once you hit enter you will login to the server via SSH as normal, then just minimize the Terminal window and leave the connection open.

One of the best parts about this technique is that you need nothing more than an SSH account on a remote server.

Using your tunnel

Now that I have the tunnel running all I need to do is tell my apps to access it. In Mail all I need to do is setup a SMTP server option that uses localhost:1025. Filemaker Pro is even easier since it uses a high port and I didn’t need to remap anything. Just point FMP at localhost and you are done.

Now I can access my services as if I wasn’t behind the firewall at all.

If you get a server that tends to time connections out quickly you can throw a command like cat on the end of your tunneling command. This will often help keep things open longer.

You can use SSH tunnels with most any of your TCP/IP based protocols. Need VNC access? Tunnel it! Need AFP? Tunnel it! (Incidentally this is the foundation for Apple’s “Secure AFP” connections.) Need IMAP? Tunnel it!

So next time you are stuck behind a firewall and need access, breakout the pickaxe and shovel and make a SSH tunnel.

Did you find this tip helpful? Am I way off base? Put you comments below and let me know!

No Comments

  • (In my opinion) the instructions don’t clearly qualify which command is to be
    performed on which Macintosh.

    Can you repost with information as to which Macintosh each command line is
    to be executed on? As well, even add the "Launch Terminal"…

    On the Firewall-secured Mac, do this…..

    On your Mac (on the oustide) do this……


  • Any chance I could get you to write a follow up about how to handle passkeys
    on either end so that you can do it all without password authentication?

    • Sure! That actually does make it easier to do server to server tunnels.

      Also check out Joel’s old article on raccoon to see how to make IPSEC tunnels
      as well.

      Breaking my server to save yours.

      Josh Wisenbaker

  • Does this article assume that access to port 22 (SSH) is available through a corporate firewall?

    • By default yes. Absolutely, no.

      By default ssh runs on port 22, but you can run it on anything you

      Let’s say I wanted to run it on port 80, which will pass through most firewalls.
      As long as port 80 isn’t in use by, oh, say Apache, I can start up a second
      sshd daemon on the port.

      sudo sshd -p 80

      Then on the client I just need to specify the port to connect to:

      ssh -p 80 -l josh

      All done!

      Breaking my server to save yours.

      Josh Wisenbaker

      • Playing the devils advocate I would ask the following questions?

        What happens when you get caught bypassing the comapany firewall and violating company security policy?

        Can’t catch me you say…. it’s all encrypted you say……

        Good information, but as Elmer Fudd would say "Be verrrwwy carefull"

        Already got another joblined up? 🙂

        • Hmm… Well this brings up all sorts of interesting questions.

          For whatever reason SSH is allowed where I am right now. So I am really just
          using the access that is provided. So is that in violation of anything?

          The ports I am mapping are SMTP, FMP, and sometimes FirstClass or FTP.
          Since these are protocols that I need to do the job they contracted us for
          would they prefer that I _not_ have them?

          The corporate engineer over the entire project commended my
          resourcefulness for using SSH like this to get the job done, although I haven’t
          run it by the data security people. 🙂

          Breaking my server to save yours.

          Josh Wisenbaker

  • In my experience, most savvy netadmins will make sure that any port
    open on
    their firewall is open for a reason: some process or server is running on it. So
    what happens when you try to open an ssh connection through port 80
    instead of port 22, and the company webserver is operating on port 80?

    Well, yes. Which is why I said if you are going to run sshd on 80 then nothing
    else should be using that port. 80 was just an example of a commonly open

    In addition, what happens if you have a firewall with stateful packet
    inspection, and it looks inside the packets? Since many firewalls are
    configured to deny all traffic not specifically allowed by rule, won’t the ssh
    connection fail because the firewall can’t see inside the packets to determine
    what they really are? And even if it could look inside the packets, wouldn’t the
    firewall see that they aren’t http traffic, and so deny them altogether?

    In this case the SSH would probably be dropped. All of this depends on you
    being able to get SSH through the firewall.

    Breaking my server to save yours.

    Josh Wisenbaker

  • So does Fugu and AFP548’s Vapor.

    Lots of people want to know how to do these by hand though, so that’s what this is targeted at. Knowing how to do them the manual way is also needed when setting up things like automatic backups via rsyncX and such.

    Breaking my server to save yours.

    Josh Wisenbaker

  • Your mac won’t connect to itself on port 548. Here’s what I use:

    ssh -fNL 10548:localhost:548 USER@SERVER

    Substitute your username for USER, and the remote machine for SERVER.
    Then, in Connect to Server, you enter afp://localhost:10548 to connect to the
    non-default port.

    The flags: -f put the ssh session in the background after authentication but
    before configuring the port redirect. That way you can keep using the same
    terminal session for other stuff. The -N flag tells SSH you’re not going to send
    the machine a command; SSH won’t go into the background otherwise. If
    you’re on a slow link, you might want to use -C also, to enable compression.

Leave a reply

You must be logged in to post a comment.