Trilight Zone

[digital8]

SSH is a secure shell. This means that it is a program that allows computers to securely connect to other computers over a network. SSH is often confused by newbies with SSL, (Secure Sockets Layer) which is a completely different animal.

SSH supports encrypted authentication, making it difficult, if not impossible for a malicious user to sniff passwords, engage in DNS spoofing, or any of the other attacks possible on a less secure connection, such as telnet.

Here is a quick picture of the client/server model for SSH.



End of primer. Brevity rulez...hehe
------------

Let's define a few variables:
sshHost - the computer you actually execute ssh on.
sshdHost - the computer you login to with ssh; the one that then asks for a password; the one where an ssh daemon is running.
freeHost - a computer in the free world
randomPort - a dynamically allocated port your system alocates as necessary.
a, c, x, z, s - specific (you specify) ports; usually c and z are blocked ports, while a, x and s are unblocked from your location.
b, y - specific (you specify) host addresses somewhere on the
internet, usually things you want to get to like public
proxies, news servers.

If you run ssh on the computer called sshHost, then:
ssh -L a:b:c -R x:y:z sshdHost
logs you into sshdHost (which *must* be running sshd).
It sets up a port 'a' listener on sshHost and connections there are sent to computer 'b' on port 'c' (probably a proxy, in the normal use of this technique). It also sets up a port 'x' listener on 'host',which sends data on to host 'y', port 'z'.

It actually makes these three connections for you:
1) sshHost:randomPort -> sshdHost:22
2) sshHost:a -> b:c
3) sshdHost:x -> y:z
You could see these with netstat.

The first time you read the following paragraph, use sshHost = home and sshdHost = freeHost. But then read it again with
sshHost = sshdHost = freeHost, and remember that in this case, the tunnels are not important - the listener's are the important thing.

Both 2) and 3) pass their connections through the encrypted tunnel, and you can see that while 2) starts from sshHost, and
goes through the tunnel to sshdHost, 3) is conceptually more difficult. Believe it or not, 3) does the same thing backwards. It allows things to connect to sshdHost:x and passes that data back through the tunnel to sshHost, where the ssh client sends it to y:z.

When sshHost = home, 3) means your own computer would attempt to connect to y:z. If z is blocked that won't work.

When sshHost = sshdHost, both 2) and 3) involve (encrypted) data flowing from one socket to another on sshHost and then on to b:c or y:z. Useless? No! You have specified unblocked values for a and x. You may connect to them from home and it's the same as connecting directly to the blocked b:c, or y:z.

There is a option for ssh, which enables it to behave as a Socks 4 proxy. Recent versions of ssh are necessary for this to be available.

ssh -D s sshdHost
will log you in to sshdHost and start a Socks 4 proxy port listening on sshHost, port s. When you connect Socks clients to sshHost:s, the requests are handled on sshHost, but the resulting network connections are performed from sshdHost. It's a distributed Socks 4 proxy. The internal communications of this proxy take place over the encrypted tunnel set up by the ssh login.

So, for sshHost = home, and sshdHost = freeHost, you have a Socks proxy which spans the censor's firewall. All your socks-capable, or socksifiable applications can run uncensored.

This command option may be combined with the '-L' and -R' options.