An Introduction to SSH
One of the nicest aspects of Linux is that it can be very command-line (terminal) driven. This can also be seen as a drawback by some, but as a result of this architecture, once one has a terminal session (shell), you have full access. One can even launch remote sessions, such as through VNC.
An early feature of network-connected UNIX systems was the advent of remote terminals. This would allow an administrator to login to a mainframe remotely and perform their duties from anywhere on the network. Originally the telnet protocol was used, which literally echoed keystrokes across the network to the server. However, as shells became more advanced, their remote counterparts followed. One popular implementation was with rsh, the Remote SHell, which also allowed things such as remote process launching. This, like many early protocols, was before the advent of the Internet, when computing networks were assumed to be (and actually were) a much more friendly environment. However, times have changed. One must assume that any network traffic traversing an unknown network, such as the Internet, will be used for nefarious purposes.
Since remote shells were developed for system administration, malicious users targeted them immediately. In light of this, SSH, the Secure SHell, was created. SSH is a versatile, cryptographically secure utility which allows a remote terminal session. All network communication is encrypted using public key cryptography, the same cryptographic framework that underlies SSL. Any malicious party intercepting the traffic while en route to its destination cannot will not be able to make sense of the data.
However, SSH is much, much more.
SSH Tunneling
SSH provides a mechanism to encrypt arbitrary traffic and tunnel it to an endpoint. This allows SSH to 'armor' insecure protocols, such as telnet or VNC, and transport it securely across an untrusted network.
As a basic application, consider VNC tunneling. VNC is an insecure protocol which expects network communication over a single port, such as 5801.
That is, a client running on a host establishes a remote connection across the network to a server listening on port 5801, as shown below:

However, with the SSH armoring, a virtual tunnel is established from a source port on the client which is transparently redirected by SSH to a destination port. For instance, the local port 5801 can be pointed to the server's 5801, which is already listening for VNC traffic. This redirection is sent through the Internet to the SSH server, which typically listens on port 22 (one of the 'system ports' which lie below 1024 and are reserved for system-level services). Then, the traffic re-emerges on the server and talks to the insecure port solely within the server itself.

This means that the insecure session has now been secured.
More complex schemes can be constructed, using an SSH server as a relay to conduct insecure sessions on a third machine; however, this is more advanced.
To establish this particular connection scheme, only a single command is necessary. On the client, log into the designated host with the following command:
user@client$ssh user@server -L5801:localhost:5801
Then, using the VNC client connect to localhost:1 instead of server:1.
