Management Through SSH

SSH (Secure Shell) is a secure alternative to the ancient Telnet program/protocol. Telnet (and SSH) allows a user to connect to a remote server, and enables the users to use a command line interface to execute commands (manage the server).

Where Telnet is relatively limited in its functionality, SSH has a bunch of features which enables the user to do much more. The SSH protocol has the possibility to tunnel traffic through an SSH connection (read: tunnel). The big advantage is that everything going through the tunnel is heavily encrypted (which is good).

The tool best known to use SSH is SFTP (FTP over SSH). A secure alternative of the 'old' (in plaintext communicating) File Transfer protocol.

Besides the advantages of directing traffic to a specific server (e.g. to a SQL Server / port 3306), you can also use a SOCKS Proxy for dynamic mapping. This enables you to surf the web through the SSH Tunnel. Your exit point / node on to the Internet appears to be the SSH Server. Just configure the SSH client to be a SOCKS Proxy and configure your Internet Browser to use a SOCKS Proxy with the appropriate settings.

Basic operations mean that you create a 'listener' with the SSH client. Direct traffic to that listener and the SSH client transports it to the other side through the tunnel.

Let's say you want to access the MySQL database on a server. Normally you'll connect to a server using it's name/IP and the MySQL management port (3306). In this case you create a listener on your localhost to listen for MySQL traffic. If you have a database running on your localhost you need to use a different local port number and instruct the SQL client to use a different port (alternative).

Listener: 127.0.0.1:3306 -> <server/IP>:3306
Listener: 127.0.0.1:13306 -> <server/IP>:3306 (alternative)

This would translate to the following SSH command;

> ssh -L 3306:<MySQL Server>:3306 <username>@<SSH Server>
> ssh -L 13306:<MySQL Server>:3306 <username>@<SSH Server> (alternative)

Another great advantage of tunneling through SSH is that you'll need only one open port on your gateway/firewall. Combine that with the possibility of strong authentication (public key) within the SSH protocol and you can be extremely safe.

NOTE: Most of the features available are configuration settings on the (SSH) server side. So if forwarding is disabled on the server, you'll be 'in trouble'.

In the old days, you were left with the command line commands in creating these tunnels and 'forwarders'.

ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
[-D [bind_address:]port] [-e escape_char] [-F configfile]
[-i identity_file] [-L [bind_address:]port:host:hostport]
[-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
[-R [bind_address:]port:host:hostport] [-S ctl_path]
[-w local_tun[:remote_tun]] [user@]hostname [command] 

Thankfully, this is no longer the case. There are lots of SSH tools available on almost every platform. Below are some of the software options around. I'll discuss some of them in more detail. I'll be using an example for the SSH clients. This way you'll get an idea of you're able to do.

Windows

• Bitvise Tunnelier (Free for personal non-commercial use)
• VanDyke SecureCRT (Commercial)
• PuTTY (Free)

OSX

• SSH Tunnel Manager(Free for personal non-commercial use)
• Meerkat (Commercial)
• Finder / Terminal (Free, builtin in the OS)

Linux

• PuTTY (Free)

Meerkat

MeerkatAt the moment my choice on the OSX platform. The interface is excellent and intuitive (you do need some minor SSH understanding).

You can create a bunch Tunnels/Profiles, and associate traffic to be tunneled with those tunnels. They even have the possibility of launching programs (or executing scripts) when you establish a tunnel.

The interface is basically split in two. There are the Accounts. These are the actual SSH servers. Along with the proper credentials for logging in.

The other part (where the magic happens) is the Tunnel interface. Here you create the tunneling parameters.

In this case I created a dynamic Socks Proxy on port 1080. So when I tell my browser to use a (socks) proxy on 127.0.0.1 port 1080, it will tunnel all traffic to the SSH server, where is forwarded to the Internet. This way, my Internet traffic originates from the SSH server instead of my own PC.

Bitvise Tunnelier

Nice interface with more than enough options. Has build-in (MS) Remote Desktop and SFTP capabilities. Apart from those features it's basically the Windows equivalent of Meerkat on OSX (which is a good thing).

First you create the SSH server with the account credentials for logging on.

After that you can use the included functionality provided by Tunnelier like opening a SFTP, Remote Desktop (Windows SSH Servers only) or Terminal/Console.

The C2S Forwarding tab is the place to create your forwarders. In this case a connection to the MySQL Database (port 3306) where I would connect locally to 127.0.0.1:13306 which should get forwarded to the Windows server (running the SSH server).

Afterwards I can use a regular MySQL admin tool to connect to the database in a secure fashion

PuTTY

Possibly the oldest of the SSH clients. It features a terminal/console (which looks like the good old MS-DOS box on the Windows platform), and a configuration part where the SSH Port Forwarding can be configured.

The nice thing about PuTTY is that it's just one tiny executable. So it's very portable. Downside of this program when you close the terminal/console, you also close the tunnels.

Anyway, starting the executable gives you the configuration screen of PuTTY. This shows the possibilities you have with PuTTY. The configuration options are vast.
The Session part of the menu holds the SSH server you want to connect to.

While the Connection -> SSH -> Tunnels holds the Port Forwarding part of the program.

Here I created a tunnel for FTP, where the local listener is port 10021, which gets forwarded to the SSH server (which in this case also runs an FTP server on port 21).

VanDyke SecureCRT

SecureCRT is a SSH terminal/console with the possibility of tunneling other traffic. Since this is a commercial program, I wouldn't recommend this if you're only gonna use it for tunneling traffic and an incidental console use of the program. You'd be better of with PuTTY.

With SecureCRT, the forwarding magic happens in the Session Options. So you need to create a session first.

After this you open the session options from the menu (Options -> Session Options), and open the Connection -> Port Forwarding category.

Here I created a port forwarding for Windows Remote Desktop to the server running the SSH server software. The local Remote Desktop client would connect to 127.0.0.1:13389 to establish a connection.