SSH or Secure Shell is a suite of programs which provide encryption of sessions between computers.  The encryption begins before the username/password  conversation starts thus providing a mechanism for no plain text passwords traveling over the intra/internet.  Secure Shell also provides a better means  of authenticating host computers helping to prevent address spoofing attacks.

The discussion which follows is for SSH Version 2.x where appropriate  references to SSH Version 1.x will be included.

AUTHENTICATING REMOTE HOSTS
When a SSH session begins the two computers exchange host keys.  These keys are created when the SSH program suite is installed and are used to authenticate  the computer instead of using the IP address.  If this is the first time you  have connected to this computer a message will appear stating  Accepting host hostname key without checking.  In your home directory a  subdirectory named .ssh2 is created and within that is a subdirectory named  hostkeys.  Within this hostkeys directory a file named key_22_hostname.pub is  created for each ssh server you connect to containing the public key for that  host.  If the server's host key has changed since the last time you connected you will receive a message telling you that the key  has changed and that this could possibly indicate a "man in the middle attack".  It will then ask if you want to accept the new key and have it replace the previous one.  It is quite possible that the administrator of the computer has changed the key as a security precaution but it is up to you to decide whether to accept the key or refuse to make the connection until you can verify whether the key has been legitimately changed.
SSH Version 1.x creates a subdirectory within you home directory named .ssh.  A file named known_hosts within the .ssh directory contains the listing of hosts you have connected to as well as their public host keys.  As with SSH2.x you will receive a notice when a new key is added and a warning message when a previously stored key does not match the currently supplied key prompting you for what action to take.

AUTHENTICATING USERS
SSH provides three means of user authentication: publickey, password, and hostbased.  With  publickey authentication a user creates a public/private key pair which is used to allow access.  While this is the most desirable method of authentication it has the drawback of allowing the user to create the key pair without a passphrase for additional protection.  That would mean that if the computer was compromised by some means then your keys could be used to connect to another machine without providing any verification that you were the person which created the key pair.  Because of this reason publickey authentication to core computers which we administer is disabled.  With password authentication you are prompted for your password on the machine you are connecting to.  With this method your password response is at least encrypted thus meeting our immediate goal of no plain text passwords flying around the network.  With hostbased authentication one creates a trust relationship between computers which allows user connections without providing any authentication (similar to the Berkeley r commands).  This method is a bit more secure that the r commands because the connecting computer is verified by its public/private key pair instead of IP address.  Hostbased authentication between core machines administered by the staff is provided automatically.  Hostbased authentication can be expanded by the users but only machines on the private network (172.29) are allowed to utilize hostbased authentication with core administered machines.  This means that hostbased authentication will not work between a core machine on the public network and a private network machine but will work in the other direction.  Our premise is that we can "trust" machines on our  private network but not on any public network including our own.  Hostbased authentication using SSH1.x is disabled.

SETTING UP SSH
Publickey Authentication
Though we do not support publickey authentication locally it can be set up to connect to remote computers.
For ssh2.x use the command: ssh-keygen -b 1024 -t dsa this will create a 1024-bit public/private key pair utilizing the DSA algorithm.  You will be prompted to provide a passphrase for key protection which you will be prompted for each time the key is used. (We will leave it up to the user to  scan the man pages to learn how to create the key without a passphrase.)  This will create some new files in your .ssh2 directory: id_dsa_1024_a, id_dsa_1024_a.pub and random_seed. The first is your private key and the second is your public key and the last is used to seed the random number generator used to create your key pair.  You private key should be only accessible to yourself with no group or other access.  Since you  can create many keys you must now inform ssh which ones you wish to use for authentication.  In your .ssh2 directory you must create two files named identification and authorization.  The identification file contains the private key file(s) used to identify the user; it is a list in the form IdKey private key file name with each entry on a separate line.  All the private key files should be located in this directory.  The authorization file contains a list of public key file(s) used for logging into this account; the list is in the form Key public key file name with each entry on a separate line.  All public key files should be located in this directory.  These files should be accessible by the owner only.
How it works: a brief introduction without the technical mumbo jumbo.
HostA is the computer you are using locally --  HostB is the computer you wish to connect to.
On HostB you copy HostA's public key to your ~/.ssh2 directory (calling it public_key_hosta.pub or some such meaningful name).  Next edit the ~/.ssh2/authorization file on HostB and add the entry Key public_key_hosta.pub.  Now on HostA you enter ssh HostB; after all the key passing, cipher negotiation and host authentication is done HostA sends a message digitally signed using your private key.  HostB attempts to decrypt the signature using the public keys referenced in the authorization file and if successful you are granted access.
For ssh1.x use the command ssh-keygen1 which if you take the defaults creates your public/private key pair in your ~.ssh directory named identity and identity.pub along with the random_seed file.  Publickey authorization is handled by the file authorized_keys which your create in the ~.ssh directory.  In this file you store all the user public keys allowed to access your account; each entry is separated from the next by a blank line.  This file should only be accessible by the owner.
Password Authentication
If publickey authentication fails or is disabled you will be prompted for your password.  At this point the session is already encrypted so entering your password is fairly safe.
Hostbased Authentication
Hostbased authentication allows access to your account based on a hosts public/private key pair and an entry in either your ~.rhosts or ~.shosts file.  For ssh2.x create a directory named ~.ssh2/knownhosts and copy into it the public hostkeys for each host you wish to grant access from.  The file names must be hostname.domainname.ssh-dss.pub.  The entries in the ~.rhosts (used by both the Berkeley r commands and ssh) or ~.shosts (used only by ssh) file must contain the host name with the fully qualified domain name.  Remember that machines administered by the core staff will only allow hostbased access from connections originating from a host on the 172.29 network.
For ssh1.x a file named ~.ssh/known_hosts is utilized.  It contains the fully qualified hostname followed by its host public key with a newline separating each entry.  Again staff administered machines will only allow hostbased access from machines on the 172.29 network.

USING SSH
The ssh command has two forms: ssh hostname and ssh hostname command.  The first form is for an interactive login session and the second is for remote execution of a command.  If you have a different login name on the computer you are connecting to use the -l flag ssh -l remote_username hostname.  For either form you may be asked to supply your public/private key passphrase and or password or be authenticated automatically if hostbased authentication is enabled.  The order and type(s) of authentication are prescribed in the system configuration files so each site may vary.  After a successful authentication you may receive a message "Authentication successful" followed by  the normal system login messages and then your command line prompt if it is an interactive session.
The user ssh2_config file
You can create a ~.ssh2/ssh2_config file to put ssh options in instead of specifying them on the command line.  The most useful of which is specifying a shorthand notation for machine names and to include remote usernames.  The form of the file is as follows:
Tag:
        OptionType     Argument

An example:
hostA:
          Host    hostA.way.overthere.com
          User    jane
Now when invoking ssh hostA hostA.way.overthere.com is contacted utilizing username jane.
When things go wrong; some connection problems and solutions
When using ssh2.x to connect to a host which does not support ssh at all you should get a similar error message: FATAL: Connecting to "host" failed: TCP/IP Failure  Solution: you must resort to insecure telnet.
When using ssh2.x to connect to a host which supports ssh1.x only you should get a similar error message: Disconnected; protocol version not supported  Solution: use the ssh1 command to connect (the core machines are configured to test for a ssh1 connection if a ssh2 connection fails).
When using ssh1.x to connect to a host which does not support ssh  you should get a similar error message: Secure connection to "host" on port 22 refused  Solution: use insecure telnet.
When using ssh1.x to connect to a host which only supports ssh2.x you should get a similar error message: Connection closed by remote host  Solution: install ssh2.x or use insecure telnet.
Other useful ssh services
sftp: secure ftp provides an encrypted ftp session with secure login.  To login using a different username you must specify sftp user@host when invoking.  Since the files to be transferred must be encrypted at one end and decrypted at the other transfer times are much slower so it is not recommended to transfer data frames in this manner.  There is also no way to specify an alternate filename when transferring files thus a file with the same name in the destination directory will be overwritten if permissions allow.
scp: secure copy provides an encrypted session for transferring files similarly to the rcp command. To put a file on a remote host the command is  scp localfile user@remotehost:/dest/dir/for/file/filename and to get a file from a remote host the command is scp user@remotehost:/dir/for/file/remotefile /dest/dir/for/filename/filename