Did you notice those extra switches earlier? -f will put SSH in the background before executing a command; -N stops the execution of remote commands; -i allows you to specify a file for private key, for passwordless connection – other than the standard file locations in ~/.ssh/
Through the firewall
There’s much more to SSH tunnelling than keeping your emails from prying eyes. If you’re on site and the client company’s firewall is blocking ports you need, such as Jabber, set up the tunnel and configure your client to use the appropriate port on localhost.
Similarly, you may find access to a security-related site blocked by overzealous content filtering, and need to tunnel browsing through a machine outside the filter: this time we need to set up a different sort of tunnel, a SOCKS proxy.
Sock it to me!
ssh -C -D 1080 -p 443 root@ myserver.com
-D is for dynamic port forwarding, creating a SOCKS proxy, over which many services can be carried at once. However, the client applications (such as Firefox), need to be capable of using SOCKS, and need to be configured in the application’s preferences.
1080 is the default port for SOCKS. Others may be tried, but won’t work with all software. Get your server to listen on port 443, instead of the non-standard ports we suggested earlier, and you’ll find your way unblocked as most firewalls allow 443 for https://.
-C turns on compression, which speeds up non-binary (ie text) downloading.
Surprisingly, you may need to tunnel SSH itself through SSH. For example, where the machine we need to reach is invisible to the outside world:
ssh -l username -L 6655:hiddenmachine:22 gatewayserver cat -
SSH over SSH
Now we can SSH to the chosen port (6655) on localhost, and we will be executing commands on the hidden server. You can also execute slogin, SCP or SFTP via localhost, port 6655 – tunnelling right through the gateway machine (visible server).
Power of reverse
A reverse tunnel lets you connect to a NATed machine, without a public IP address. The NATed machine opens a reverse tunnel to a server, and from the server one opens a connection to localhost and the chosen port which connects you back down the tunnel.
From a third machine, connect to the server. Then SSH to localhost and you are also connected to the NATed machine. This means from anywhere you can connect to a desktop without an SSH server, if it can run a client.
Some desktop software effectively tunnels through SSH for you, such as your file browser. In Nautilus, go to File –> Connect to Server and put in your SSH details. In Konqueror enter fish://user@server in the location bar.
Drag and drop
Now you can work on remote sites alongside your desktop and locally mounted shares. Who needs Dropbox? Note that as well as SSH, you can do this over FTP or HTTP (WebDAV). GUI-haters can use MC (from the Right menu, select ‘shell link’), or mount with SSHFS.
At its simplest, tunnelling X applications means never having to battle dependencies to install difficult apps on your PC, so long as they’re running on a machine to which you have SSH access with X forwarding enabled. In practice, machines on local networks give best (least laggy) results.
Nevertheless, graphical apps can be run from servers hosted in another country, as long as you are prepared to put up with a little lag in busier apps. You could even browse BBC iPlayer on a UK-hosted box while travelling overseas.
Beyond forwarding Z apps, we’ll have a bit more to say on VNC and remote desktops next month, when we conclude our look at secure remote network apps and look at the more permanent alternative to SSH tunnels – the virtual private network or VPN.