SSH stands for Secure Shell. it enables the privacy of fully encrypted sessions between you (client) and another machine (server). If you go to http://openssh.org you will find source code which will work on most versions of Unix, and pointers to options for other OS's, including Windows and MacOS (I've had good results with 'putty' on Windows).

Simple Usage:

In it's most simple form, an ssh session can be initiated by the command:

ssh remotebox

SSH will attempt connect to the ssh daemon on remotebox and log you in with the same username as you're using on the local box. If you wish to login to remotebox with another name,

ssh otheruser@remotebox

or ssh remotebox -l otheruser

will both attempt to log you in as the user otheruser, much like with rsh.

You can also specify remote commands a'la rsh or rcmd. Analogous to ssh, is scp – scp is designed to be a drop-in replacement for rcp and (mostly) works the same. The simple setup will use password authentication.

Machine Authentication

ssh uses public key encryption to identify servers – much like with SSL, but without the centralized key distribution that SSL uses. When a server starts up sshd the first time, ssh will generate a pair of private key files in the /etc/ssh directory. The two files will be named ssh_host_rsa_key and ssh_host_dsa_key. if your machine accepts older ssh1 connections, then it will also create ssh_host_key. The key files are known as the host private key. They are readable only by root and should remain that way. if anybody gets hold of those keys, they will be able to impersonate your machine.

Each of private key file will have an associated file who'se name will end in .pub . Those files are known as the host public key and are given to pretty much anybody that asks. The .pub file allows anybody to uniquely identify the machine holding the associated private key. Normally only the RSA key is used. The DSA key method was used to avoid infringing the RSA patents (which expired a in 2000) and is considered 'almost as good' as RSA.. The ssh1 protocol is considered 'broken' and should only be used when a client has only ssh1 capability and minimal protection is 'good enough'. (hint: get them a current copy). ssh1 can be disabled by editing the sshd_config file.

Public Key (RSA) Key Authentication

Although SSH uses encryption when transmitting a user's password, transmitting the password is still considered problematic. Using Public key authentication is preferred, since it allows a challenge-response cycle which uses a challenge/response cycle that depends on access to a private key and (usually) the password to encrypt it. The challenge/response cycle does not actually transmit the private key.

To enable RSA authentication you must create a public/private key pair (roughly the same process as is used for the host key) This is done using the 'ssh-keygen' program.

ssh-keygen -t rsa

will create an ssh2 RSA key, and ask you for a passphrase to encrypt the key. If you just hit return, it will create an unencrypted key. This will allow for passwordless logins (with associated security problems) using the private key file.

If you don't specify a specific file name, ssh-keygen will create a private key file $HOME/.ssh/id_rsa and the associated *.pub file. if you append the contents of the .pub file to $HOME/.ssh/authorized_keys on remotebox, you can then use the private key to login to remotebox. When you ssh to remotebox, ssh will then ask you for the key to decrypt the (local) private key instead of the password to the remote account. If you didn't provide a password when creating the private key, then login will proceed without any password/key – posession of the unencrypted key is considered equivalent to a password.

using multiple keys:

ssh-keygen allows you to specify non-default locations for your private key. You can specify use of such non-default keys by going:

ssh -i private_key_file

the contents of the private_key_file.pub file must still be appended to the authorized_keys file on the remote host. Non-default key files are especially useful for things like passwordless logins for specific purposes.

If you prepend an entry in .ssh/authorized_keys with the option 'command=”some_command” ' then that key will only be able to be used to run the command some_command. e.g.

command="/bin/df" ssh-rsa AAAAB3[...]hfVdzs user1@mybox

will only allow the user1@mybox key to be used to run the /bin/df command. This is especially useful with unencrypted private key files to minimize the damage should the file fall into the wrong hands.

X-Windows Forwarding

SSH also allows X-11 sessions to be transparently forwarded from the remote machine... In other words, once it is enabled, I can login to a remote machine and stat up (say) SMC, and the display will pop up on my local display. This requires editing the '/etc/ssh/sshd_config' file so that it contains the line:

X11Forwarding yes

(sshd will need to be restarted after editing the config file)

Once the daemon allows forwarding, you can enable it for a session by specifying the '-X' (capital X) option to ssh – or by editing the '/etc/ssh/ssh_config' file to contain the line

ForwardX11 yes

Note that, although X11 forwarding is very convenient, it is disabled by default because there are security issues associated with having it on. If you're connecting to a host that you don't especially trust, you can force X11 forwarding off with the -x (small x) option.

In situations where I require rsh/rcmd/rcp features with more security than those commands offer, I'll replace the r* commands with their s* equivalents.

Other uses for SSH

SSH has many capabilities beyond what's documented here. For more info, man the various commands (ssh, scp, sshd, ssh-keygen ssh-agent and sftp) and/or ask around.