The Answer Gang

Piercing the Veil

Using OpenSSH Remote Tunnels to Get Back In

Answered By Jim Dennis

Problem: You're using a system at work that's on an internal (non-routable) IP address (as per RFC1918), or that's behind a set of proxy servers or IP masquerading routers. You want to work from home, but you can't get into your system.

WARNING: This hack may be a violation of the usage policies either of the networks involved! I'm describing how to use the tool, you assume all responsibility for HOW you use it. (In my case I'm the one who sets the policy; this is just a convenient trick until I get around to setting up a proper FreeS/WAN IPSec gateway).

Let's assume that you have a Linux desktop or server "inside" and another one "at home" (obviously this trick will work regardless of where "inside" and "at home" really are). Let's also assume that you have OpenSSH installed at both ends. (It should work with any version of SSH/Unix and possibly with some Windows or other clients, I don't know).

As root on your internal machine, issue the following command:

ssh -f -R $SOMEPORT:localhost:22 $YOURSELF@$HOME 'while :; do sleep 86400; done'

... this will authenticate you as $YOURSELF on your machine, $HOME and will will forward tcp traffic to $SOMEPORT on $HOME back trough the tunnel to port 22 (the SSH daemon) on localhost (your "inside" machine at work). You could forward the traffic to any other port, such as telnet, but that would involve configuring your "inside" machine to allow telnet and (to be prudent) configuring its TCP wrappers, ipchains etc, to disabled all telnet that didn't come through (one of) our tunnels.

The fluff on the end is just a command for ssh to run, it will loop around forever (the : shell built-in command is always "true") sleeping for a whole day (86400 seconds) at a time. The -f causes this whole command to fork into the background (becomming a daemon) after performing any authentication (allowing you to enter passwords, if you like).

To use this tunnel (later, say from home) you'd log into $HOME as yourself (or any other user!) and run a command like:

ssh -p $SOMEPORT $WORKSELF@localhost ...

or:

ssh -p $SOMEPORT -l $WORKSELF localhost

... Notice that you use the -p to force the ssh client to connect to your arbitrarily chosen port (I use 1022, 2022, etc. since they end in "22" which is the IANA recognized ssh protocol port). The -l (login as) or the form $WORKSELF@ are equivalent. Note that you user name at work needn't match your name at home, but you must use the "REMOTE" username to connect to the forwarded port.

That bears repeating since it looks weird! You have to use the login name for the remote system even though the command looks like your connecting to the local host (your connection is being FORWARDED).

If you use these commands you can log into a shell and work interactively. You can add additional arguments to execute non-interactive commands, you can set up your ssh keys (ssh-keygen, append $HOME/~/.ssh/identity.pub to $WORK~/.ssh/authorized_keys) so that you can gain access without typing your password (though you should configure your ssh key with a passphrase and use ssh-agent to manage that for you; then you only have to enter you passphrase once per login session to access all of your ssh keyed accounts).

You can also copy files over this tunnel using the scp command like so:

scp -P $SOMEPORT $WORKSELF@localhost:$SOURCEPATH $TARGET

... not that this is an uppercase "P" to select the port, a niggling difference between the syntax of the ssh client and that of the scp utility. Of course this can be done in either direction; this example copies a remote file to a local directory or filename, we're reverse the arguments to copy a local file to the remote system.

As I hinted before, you are actually double encrypting this session. You tunnel to the remote system is encrypted, and in this case the connections coming back are to a copy of the sshd back on your originating machine; which does it's encryption anyway. However, the double encryption doesn't cost enough CPU time to be worth installing a non-encrypting telnet or rsh and configuring it to only respond to requests "from" localhost (from the tunnels).

One important limitation of this technique: Only one remote user/session can connect through this tunnel at a time. Of course you can set up multiple tunnels to handle multiple connections.

This is all in the man pages, and there are many references on the net to using ssh port forwarding, but finding an example of this simple trick was surprisingly difficult, and it is a bit tricky to "grok" which arguments go where. Hopefully you can follow this recipe to pierce the corporate (firewall) veil and get more work done. Just be sure you clear it with your local network and system administrators!

This page edited and maintained by the Editors of Linux Gazette Copyright © 2001
Published in issue 70 of Linux Gazette September 2001

HTML script maintained by Heather Stern of Starshine Technical Services, http://www.starshine.org/

1   2   3   4   5   6   7   8   9   10   11