SSH Cheat Sheet
===============

You can generate a key pair consisting of a public key (which everybody 
is allowed to know) and a private key (which you keep secret).

DEFINITION:  Signature - The private key is able to generate signatures. 
A signature created using a private key cannot be forged by anybody 
who does not have that private key; but anybody who has your 
public key can verify that a particular signature is genuine.

~/.ssh/known_hosts    - The file holds a list of public keys issued by host 
                        (server) computers that I ssh to. Once a host key has 
                        been accepted by me (after the first time I ssh to the
server, and then choose to accept the host key, which is given as a warning),
connecting to that machine again doesn't issue warnings any longer.  The 
known_hosts file is searched during each ssh connection attempt, and if
the signature issued by the host can be validated against the stored public
key, then this connection is accepted without warning.  
If the host key changes (or perhaps the URL of the host?), you will see a nasty 
looking ssh warning during the next connection.  
You can simply erase the entry from the known_hosts file, which
effectively means you are starting over again with this server (you will
again receive the first warning and must accept that key again for inclusion
in the known_hosts file).


ssh-keygen -t rsa     - Command to generate a public / private key pair using
                        the type of key: RSA. This currently defaults to 2048 bits.
                        These keys are stored as files here:
~/.ssh/id_rsa.pub     - File containing the public key
~/.ssh/id_rsa         - File containing the private key

Keep private key well guarded (set permissions for user read-only).

If you choose not to use a passphrase, the private key is unencrypted
in that file (so really be careful), but this means you don't have to
type a passphrase each time you want to use it.  Essentially a passphrase
is like a password for your key -- every time you want to use the private
key, you have to enter the passphrase to get at it.

You may not want to use a passphrase for 2 reasons: 
1) Typing a phrase is inconvenient when you want to log on to other systems frequently
2) If you want to execute scripts non-interactively that make use of ssh
   (such as an rsync script which backs up to a remote server, especially
    if it is run unattended as a cron job).

A passphrase will stop someone from stealing your private key and being able
to login to 'any' machine that you have your public store with.

You may generate multiple keys, some that are passphrase protected
and some that are not.  A non-passphrase key can then be restricted on the host 
machine to only perform a specific task (eg, run one particular script), while the
passphrase-protected could be used for general logging in.

~/.ssh/authorized_keys2    - If the computer is running as a host (server) 
                             and accepts ssh connections, you may also see
                             this file. It contains all the public keys of
users who are authorized to connect.  The "2" means version 2 protocol. If
it is not present (i.e., authorized_keys), then it is version 1, which is
not current or strong.

To be able to login to a remote system using the keys, you will have to add
the public key to the server's authorized_keys2 file.  There are ways to
do this securely (including scp).

(Be sure that you're not copying over the remote host's id_rsa.pub -- if
 they are identically named, make sure to rename the new version, with
 something like  .ToAdd.  in the name.)

[user@local]$ scp ~/.ssh/id_rsa.pub user@remotehost.net:~/.ssh/id_rsa.ToAdd.pub

ssh into remote host and cat the key file contents into authorized_keys2
(Consider first making a backup of the authorized_keys2 file.)

[user@remote]$ cat id_rsa.ToAdd.pub >> authorized_keys2

You probably now want to delete the id_rsa.ToAdd.pub file:

[user@remote]$ rm id_rsa.ToAdd.pub

Now you can ssh, scp, and rsync using ssh from the local computer to 
 the remote host w/out having to enter your password.

At this point, if you plan on using this login only to run a script, the 
authorized_keys2 file can be modified to restrict the use of the login
to a particular purpose (for example, just to run a specific script, such
as rsync or a backup script).