Official website for Linux User & Developer
FOLLOW US ON:
Jun
22

SSH tunnelling on insecure networks

by Richard Smedley

Bypass overly restrictive firewalls and run safely over insecure networks in easy steps

If you’re still using SSH as just a telnet replacement, you are missing out on borrowing its secure encryption to carry many other network services through insecure Wi-Fi, and overly restrictive firewalls, from wherever you have a laptop or smartphone.

For the bulk of this article, we shall be looking at local port forwarding – the most common and the most useful type – to give secure, VPN-like connections. Why not just use a virtual private network? VPNs aren’t always available to you, and some corporate VPNs demand particular client software and configuration, but SSH
tunnels can always be created on the fly, as and when you need them.

Perhaps you have never read the SSH man page? No? Well, the options you should have been looking at are -L and -R, with a little attention to -N and -f.

Skipping lots of theory, we’ll take a practical approach and show you how to use SSH tunnelling in various common scenarios. Read on and find just what these magic switches to the ssh command can do for you, but beware – the power to run rings around firewalls should be used carefully!

Bypass over-restrictive content filtering
Bypass over-restrictive content filtering

Resources

SSH client with SSH daemon on the server

A server connected to the internet, preferably with a fixed IP address

Step by Step

Step 01

A different port

When you run a normal SSH session, it simply opens an encrypted connection from a spare port on your computer to port 22 on a remote device. For security reasons – many scripts are knocking on port 22 with well-known passwords – you can specify another port.

Step 02

Insecure access

However, inside this encrypted connection you can carry other traffic – hence SSH tunnelling. This means that however insecure your connection (eg cafe Wi-Fi), your traffic is as secure as the level of encryption used by SSH (ie good enough).

Step 03

Confidential mail

Tunnelling allows you to hide your unencrypted email traffic inside the SSH connection. The -L local-port:host:remote-port creates the tunnel, allowing SMTP (port 25) traffic from the mail-server to appear on (for example) port3909locally.

Step 04

Local config

Now just configure your email client to connect to port 3909 of the local machine. Localhost and 127.0.0.1 are synonymous, but you could also use the fully qualified domain name (FQDN) of your local machine. You can do the same for receiving mail via POP.

Local Config
Local Config

Step 05

Pick a number

Why port 3909? Port numbers below 1024 are for privileged services. No non-root users should be looking higher than this, but taking a peek at the popular ports in use by other software. Pick a free number such as 6555 or 3989 as your default.

Step 06

Two-lane tunnel

While outward-bound SMTP is occasionally blocked, if you’re tunnelling for security, best do the incoming POP mail with the same command. As you can see, multiple local tunnels can be expressed in the same ssh command, each with the -L switch.

Step 07

On the server

Before we go any further, best get a couple of things straight on our server. SSH in (without the tunnel this time), gain root privileges, and fire up your favourite editor to open /etc/ssh/sshd_config (or whatever your distro names the file).

Step 08

Security basics

As well as security settings like a port other than 22, and not allowing root login, here you should uncomment the protocol version 2 setting, so only the more secure protocol version 2 will be used. If both are listed, delete the ‘1’.

Step 09

Error check

Check you can log in on the new port from another terminal before you close this session! If there is a problem, check that you restarted the SSH server, and typed the correct port and username. If in doubt, return to default port setting.

Step 10

Keep yourself alive

While you can add ServerAliveInterval 60 to your ~/.ssh/config file, adding KeepAlive on the server will work when you connect from other devices or PCs – the ClientAlive directives will keep you connected during inactive periods, which is useful for reverse tunnels.

Step 11

Keeping track

Configs for local and reverse tunnels can also be added at the client end too – handy for keeping track of multiple connections over multiple ports, as well as enabling easier connections from shell scripts. RemoteForward = reverse tunnel.

Pages: 1 2
  • Tell a Friend
  • Follow our Twitter to find out about all the latest Linux news, reviews, previews, interviews, features and a whole more.