I have been using SSH tunnels for a long time. Usually, I just manually open the tunnels I require. But, setting up my new machine (archlinux on a Thinkpad t440s.. shiny!) I’ve been writing a lot of shell scripts to automate much of what I used to do manually.

In that spirit, I wanted a script to create an ssh tunnel and connect my irc client (irssi) to my bouncer (znc), behind my home firewall.

So, this is what I’m using:

#!/bin/bash
ssh -f -o ExitOnForwardFailure=yes -L 6667:localhost:6667 user@home.example.com sleep 30
irssi

The -f -o ExitOnForwardFailure=yes combination makes ssh wait until the forwarded ports have been established before backgrounding. Effectively, this blocks the script until the ports are ready to use.

The sleep 30 keeps the connection open (in the background) for 30 seconds before ssh terminates. However, if there is an open connection on the tunnel, ssh will wait for it to close before terminating. This means, you have 30 seconds to connect to the forwarded port, then it will stay open as long as you’re using it. So, once I quit irssi, the tunnel closes.

Then, irssi configured to connect to localhost:6667 which is tunneled to localhost:6667 on the target machine, where it finds znc!

Netcat (nc) is a really useful little utility, available for most (all?) OSs. It’s often used for low level network tinkering. Recently, I found an everyday (for me) use; Testing HTTP “Web Hooks”.

In my specific case, it was the Facebook “Real-Time” API, which POSTs data back to your registered endpoint when a given event occurs on Facebook. But, navigating to Facebook, performing an action and waiting for them to notify your server is a relatively slow process, and makes debugging painfully slow.

To overcome this, we need to be able to consistently repeat a request from Facebook while fine-tuning the handler to perform the required task.

Firstly, we can set up nc to capture the request. We could manually write a HTTP request, but this will ensure it is authentic and actually represents the request that will be sent by the third party.

nc -l 8000 > request.txt

This will cause nc to listen on port 8000 and write any incoming HTTP requests to “request.txt”. Then, we just need to coerce the target service to send us a request at the correct location (you could use port 80, if you don’t need to keep the web server running). Note: the listening nc process will not reply to the request, so the connection will stay open until the client times out or you manually kill the process. Once the request is received, it will be stored in “request.txt”, where we can view it, edit it and — most importantly — replay it.

We can also use nc to handle sending the request for us by piping the saved file through to the target server.

cat request.txt | nc myserver.example.com 80

This will connect to our server and make the exact HTTP request that was captured. The advantage, of course, is that we can replay the request over and over quickly and accurately.

As a command line junky and a Vim user, this is something I’ve been meaning to do for a long time. I mean, who actually uses Caps lock anyway? Every time I’ve had a look, the process has appeared to involve installation of third party software and in general seemed like too much effort. It turns out, if you only want to remap meta-keys (caps lock, alt, ctrl and command) you can do that easily through the OSX System Preferences.

In “Apple Menu” (Top Left), “System Preferences”, “Keyboard”. On the “Keyboard” Tab (not “Keyboard Shortcuts”), there is a “Modifier Keys” button, which opens a dialog and provides a simple interface to remap (or disable) your modifier keys.

I wish I’d realised sooner that it was so simple, now to re-train my hands and free that poor little finger from its curled up hell.