I saw an article on reddit this morning about SSH trickery. SSH is a very subversive protocol, able to work around many kinds of unwise security policies. Here’s a couple more useful things to know.
1. Better Lurking Through .ssh/config-ery.
Where you’ve got machines lurking behind other machines, inaccesible from the Internet, you can add a clause like this to your .ssh/config file:
Host: lurker ProxyCommand: ssh gateway.work /bin/nc %h %p
This causes ‘ssh lurker’ to open an ssh connection to gateway.work, then use nc (may be called netcat on your system, or you may have to install it yourself) to connect on to lurker (the %h %p interpolates the target hostname and port into the proxy command)
2. Reverse Tunnelling
So you’ve noticed the -L option, right, and you understand that by running
ssh -L 3128:localhost:3128 gateway.home
you are establishing a tunnel home to your proxy server, and you can now configure your web browser to use ‘localhost:3128′ as its proxy server to keep your web traffic private.
But did you know this one? Let’s say you’ve got a machine stuck out in DMZ land and you want to apt-get upgrade the poor thing, pronto. You can’t access the web from this box: security policy. You can’t access your internal proxy: ditto. All you can do is ssh into it. Try this:
ssh -R 3128:proxy.work:3128 dmzbox.work
From your shell on dmzbox, you can now configure the http proxy as localhost:3128 and start sucking down packages via the reverse tunnel.
3. Tunnel Tunnelling
Every now and then, you need to get control of a box which is sadly hidden away behind a broken hotel NAT network or some kind of Get Smart style VPN setup. You can’t even get an ssh in. It’s either read Unix commands over an international phone line at 3am your time, or train a pigeon to tap out the following:
ssh -L 2222:localhost:22 gateway.work
which, when run on the remote box, opens an ssh tunnel back home, through which you can ssh back into the remote box with ssh -p 2222 localhost
