What will be explained here is mostly about open source implementation of ssh – OpenSSH, so some things might be different if you’re using something else.

Let’s first see about SSH security – is it really so secure? While it’s hard to be exact on this issue one thing is certain – if you’re using SSH protocol use only it’s version 2. SSH protocol version 1 is known to have exploits for some time now and it is definitely not advisable to use it. Sure, it’s not as bad as connecting with telnet, but any reasonably well configured SSH server nowdays will offer you a SSHv2 connection and even might be limited to this option only.

Some specific issues with SSH – if you’re new to it some things might confuse you. For example – when logging in a system that you’ve never logged in before it will prompt you for a authenticity check and display you a key fingerprint.

The authenticity of host ‘somerandomserver.com (0.0.0.0)’ can’t be established.
DSA key fingerprint is 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00.
Are you sure you want to continue connecting (yes/no)?

Huh? What happens here – to prevent man-in-the-middle attacks you must be sure that you are always communicating with the right system or you might be sending passwords and other confidential information to anyone who impersonates this system. IP addresses can be spoofed, DNS entries are easily changed ARP poisoning can redirect your traffic and so on… Once you’ve confirmed that this is exactly the system that you want to login to its key will be memorized for later use and you wont see it again …unless somebody tries to fool you – then you’ll get a nice big warning about not matching the hosts keys. Needless to say, if you are not absolutely sure that system you are logging to hasn’t changed it’s keys stay away from further login!

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the DSA host key has just been changed.
The fingerprint for the DSA key sent by the remote host is
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:01.
Please contact your system administrator.

So, what exactly is it that is possible to achieve with this tool, or should I say toolbox?

Remote logins

Basic use of ssh client is
ssh hostname

Which will attempt login on host “hostname” on standard SSH port 22. After successful login you can work normally as with console or telnet.
Additional interesting basic options:
-p : port to which you are connecting to (default 22)
-l : login with different username then default (default is current users username; this can be also accomplished as with username@host syntax)
-q and -v : first is for no messages at all (quiet) and second is for verbose debugging messaging
-t and -T : disabling and enabling pseudo-tty generation at servers end (default enabled) – useful if you’re just making port forwarding
-C : request compression of the transmission data (useful for slow connections)
-o : define a option value so values from configuration file can be overridden
-1 or -2 : try only version 1 or 2 of the protocol

SFTP/SCP

Secure alternatives for commonly used (unsecure) protocols – FTP and rcp (remote copy)
scp and sftp accept most of the normal ssh client’s options (attention: port is here defined with -P unlike -p with ssh) but are used only for file transfers. scp for single file transfer and sftp for multiple file transfers.
scp use:
scp ~/somefile hostname:/tmp/somefile

This will copy “somefile” from your home directory to “/tmp/somefile” on remote ssh server. If you ommit path on remote server files will be copied to your home directory on server.
Retrieval of files from remote server isn’t much harder either:
scp hostname:/tmp/somefile ~/somefile_again

Passwordless logins

More appropriate for automated tasks but might help you if you tend to forget passwords. Basically have a private/public key with which you are authenticated on server. Of course, it’s more secure if you have password also setup on your private key – otherwise anyone who steels your private key can login into your servers. Yikes.
By default when connecting your private keys will be searched within ~/.ssh/ folder and are called id_dsa || id_rsa (depending on encryption used), but private key file location can easily be defined with -i option so you can use different keys for different servers:
ssh -i ~/secretfiles/mykey_at_hostname hostname

Of course the same applies for scp and sftp…

Remote command execution

Who says you even need a terminal?
ssh hostname df

If system command is added as parameter of the ssh connection command (in this example it’s df) after successful login it will be executed and logout happens as soon as it’s execution is finished. Useful for checking on some services; or in this case – file system capacity status.

Port forwarding (poor man’s VPN)

Forwarding a port thru remote system – weather you need it to secure traffic over not so secure link or connect to the service which is behind the firewall – this one is all time favorite ssh trick
So, presumably you need to check on some webpage which is available only inside LAN of your network from internet and you have only ssh access to server there. Imposible? Not with ssh:
ssh -L 8080:webserver:80 hostname
where 8080 is port on your client ssh computer, webserver is LAN address of the webserver in LAN and 80 is webservers http port

Now type in http://localhost:8080 in your browser and work like you’re there… As you can see -L is a very powerful option and it does forwards one port from some host (ports for localhost and remote hosts port can be set up as needed) to your local computer.
Additional use of this is anonymous surfing (or some other form of activity) – ports can be forwarded from whichever hosts your ssh server has connectivity to and port forwarding has a very interesting feature: all traffic made to that remote host seems like it originates only from ssh server and without any trace of your local computers address.

Reverse (remote) port forwarding

Forwarding a port on a local system to be available on remote system
Similar to port forwarding, but of reverse nature like it’s name says – expose your local network hosts to anybody who has access to remote servers forwarded port. Use with caution – you never know who’s listening on the other end…
ssh -R 8080:webserver:80 hostname
where 8080 is port on remote ssh server, webserver is LAN address of the webserver in LAN and 80 is webservers http port

Anyone who can access remote ssh servers 8080 port can now browse webserver in your LAN (do you really want this?). Also, with this your computer works as anonymous proxy for chosen webserver (or any other protocol depending on ports used).

SOCKS Proxy

Believe it or not, SSH can serve as SOCKS proxy
ssh -D 12345 hostname
where 12345 is port on your local computer

Huh? Is it this easy? Yep – dynamic port forwarding as it is usually called does just this – makes a SOCKS v4/5 out of your computer and all you need to do is point your SOCKS-aware applications to the chosen port…

Punching holes in HTTPS proxy

OK, now this isn’t exactly a ssh-only feature (proxytunnel does most of the work here) but might be the only way to make your way thru the corporate restrictive web policies