The Software
Associated with your general ssh client installation on a UNIX machine are the availability of certain commands-- for most folks, the important ones are ssh, scp, and sftp. scp and sftp while they use the same method of communication as your average ssh connection, are designed solely to transfer files between the client and the remote server. For more details on this topic, please see our page covering ssh data transfers.
The industry standard for UNIX systems is OpenSSH, which supports both ssh version 1 and ssh version 2 connections. Some departments or institutions (Berkeley's Astronomy department is one example) will only accept ssh version 2 connections, and will refuse any ssh version 1 connections; to ssh into those machines from a managed UNIX workstation, your client must support ssh version 2.
Using the client
The basic function is simple:
[lanclos@lacquer]$ ssh somehostname [lanclos@lacquer]$ ssh username@somehostname
Here are some typical options you might set on the command line; note that any options set on the command line override the behavior specified in the system-wide configuration file, and in your personal configuration file.
-l username
If your username on the remote machine is different from your username on the machine you're running ssh on, you'll need to supply the correct username. If the username is the same, it does not need to be explicitly set.-p port_number
If the remote host is running ssh on a non-standard port number, you'll need to specify that here.-i ssh_key
If you have a special ssh identity key that you need to use for the remote host, specify it here. If you need to use that key on a regular basis, you might want to add that keyfile to your local ssh config file rather than specify it every time on the command line.-c ciphertype
You can choose which encryption algorithm to use with ssh. This is not typically helpful for interactive ssh sessions, but can make a big difference for data transfers, especially when dealing with older, slower computers. Please see the ssh data transfer page for details about how cipher choices can affect data transfers.
There's many more options besides those few; take a look at the manual pages for the gory details.
Configuring default behavior
The system-wide config files on our Linux and Solaris hosts are updated on a nightly basis, and set reasonable defaults. The configuration file that affects the behavior of the ssh client binaries is typically found at /etc/openssh/ssh_config, or /etc/ssh/ssh_config.
You can override all system-wide settings within your personal configuration. All of your client settings wind up in the ".ssh" directory within your home directory on your UNIX workstation. Here's a sample directory listing:
[lanclos@lacquer]$ ls -l ~/.ssh total 12 -rw-r--r-- 1 lanclos nics 106 Dec 4 16:36 config -rw-r--r-- 1 lanclos nics 352 Jan 29 15:47 known_hosts -rw-r--r-- 1 lanclos nics 3095 Jan 22 21:54 known_hosts2
There are three files in that directory; the config file contains any local client options that are particular to the UNIX user lanclos, and the two known_hosts files contain specific host keys for machines that were not in the standard ssh_known_hosts (in /etc/openssh) on that specific machine.
If a machine's host key changes and you have an entry for that machine in your local ~/.ssh/known_hosts file (you will only have keys in that file if you choose to add them), your ssh client will complain about the host key changing. In order to restore normal operation, you need to edit your local ~/.ssh/known_hosts file, and remove the offending key-- the complaint tells you as much, and will tell you which line number contains the offending key.
For a verbose list of the configuration options available to you, look at the OpenSSH manual pages, specifically, the one for the ssh client. Three of the most sought-after options are the following:
ForwardAgent yes ForwardX11 yes ForwardX11Trusted yes
These allow forwarding of ssh agents, and forwarding of X11 sessions via an ssh connection; these options are among those enabled in our system-wide configuration files.
Using SSH Keys
SSH keys are useful in a variety of situations. The only purpose I will cover in this particular diatribe is how to use SSH keys to establish your local identity, and how those keys can allow to you log into other UNIX machines without requiring you to re-enter your password; this is the most common use of ssh keys.
Generating new keys
Start by logging into your favorite workstation-- ideally, the one that you're doing all your ssh'ing from; I'm going to call my favorite workstation lacquer. Here is some sample input and output from the ssh-keygen program:
[lanclos@lacquer]$ ssh-keygen -t rsa1 Generating public/private rsa1 key pair. Enter file in which to save the key (/u/lanclos/.ssh/identity): /u/lanclos/.ssh/identity Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /u/lanclos/.ssh/identity. Your public key has been saved in /u/lanclos/.ssh/identity.pub. The key fingerprint is: 33:c1:d6:20:87:52:47:d7:72:4e:15:09:0e:fc:6c:2a lanclos@lacquer.ucolick.org
When prompted, make sure to enter a passphrase. If you do not set a passphrase, anyone that is able to acquire a copy of your ssh keys will be able to use them. This passphrase can be unique, and does not need to match (nor should it match) any other password you use.
What was accomplished here? If I look in my ~/.ssh directory, I see two new files: identity, and identity.pub. The .pub version is the "fingerprint" referred to in the output above; the non-.pub version is the actual key. Do not distribute the key. The whole idea behind this exercise is for your key to be unique, and for nobody else to be able to use your key to masquerade with your identity. The .pub version, however, is meant for more wide-spread public consumption; we'll using it later in this process.
Now, when I ran ssh-keygen above, I generated a particular type of key: an RSA1 key. This is the type of key used by the old ssh version 1 protocol; ssh version 2 requires RSA or DSA keys for its operation.
[lanclos@lacquer]$ ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/u/lanclos/.ssh/id_dsa): /u/lanclos/.ssh/id_dsa Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /u/lanclos/.ssh/id_dsa. Your public key has been saved in /u/lanclos/.ssh/id_dsa.pub. The key fingerprint is: a8:6e:66:11:2b:9e:19:85:9e:06:70:82:9c:d5:d3:1b lanclos@lacquer.ucolick.org
When prompted for the passphrase, you should enter the same passphrase as you used for the RSA1 key above.
I now have keys that will work in both ssh1 and ssh2 situations; not all machines understand both protocols, so sometimes it pays to have both on-hand, though this situation is much rarer than it was when ssh version 2 was a relatively recent development.
Using the new ssh keys
The next step is to instruct your personal ssh confiuguration to use these new identities; open the file ~/.ssh/config in your favorite text editor, and add the following two lines:
IdentityFile ~/.ssh/identity IdentityFile ~/.ssh/id_dsa
In order to use these keys, you will need to add them to your ssh agent. This can happen one of two ways; if you are logged into some kind of X11 session, typically at the console of the workstation in question, you need to run ssh-add:
[lanclos@lacquer]$ ssh-add Enter passphrase for /u/lanclos/.ssh/id_rsa: Identity added: /u/lanclos/.ssh/id_dsa (/u/lanclos/.ssh/id_dsa) Identity added: /u/lanclos/.ssh/identity (lanclos@lacquer.ucolick.org)
From now on, from any xterm within my X11 session, any ssh client commands I run will attempt to leverage the keys that my ssh-agent is aware of.
If you are logged in remotely (not at an X11 console), you can still leverage ssh-agent functionality; you first need to run a new instance of your shell. For example, if your default shell is bash, you would run:
[lanclos@lacquer]$ ssh-agent bash [lanclos@lacquer]$ ssh-add Enter passphrase for /u/lanclos/.ssh/id_rsa: Identity added: /u/lanclos/.ssh/id_dsa (/u/lanclos/.ssh/id_dsa) Identity added: /u/lanclos/.ssh/identity (lanclos@lacquer.ucolick.org)
From now on, any ssh client commands I run within that specific shell session will attempt to leverage the keys that my ssh-agent is aware of.
Configuring remote clients to recognize your new ssh keys
If you want the computer on the other end to authenticate you based on these keys alone (i.e., so that you don't have to type in your standard password), you'll need to do some work on that machine as well. As an example, let's suppose that I frequently log into a particular research machine (let's call it virgo), and I'm tired of feeding it my password. First, I need to know what the public versions of my keys are:
[lanclos@lacquer]$ cat ~/.ssh/identity.pub 1024 35 110[blah blah blah]1092381 lanclos@lacquer.ucolick.org [lanclos@lacquer]$ cat ~/.ssh/id_dsa.pub ssh-dss AAAAB3N[blah blah blah]/UBR4= lanclos@lacquer.ucolick.org
Now, I need to log into virgo, configure it to recognize these keys. On virgo, I'm going to open the file ~/.ssh/authorized_keys and add the identity.pub contents listed above, with some additional syntax:way:
from="lacquer.ucolick.org" 1024 35 110[blah blah blah]1092381 lanclos@lacquer.ucolick.org
If you want to have multiple entries in this file, you enter one (long) entry per line. By formatting the individual entry in this way, I've added an extra layer of security-- my identity key will only be accepted if I'm trying to use it from the host lacquer.ucolick.org; this key will not be accepted from any other hosts.
You can add the same type of entry in your authorized_keys file for the contents of the id_dsa.pub` file:
from="lacquer.ucolick.org" ssh-dss AAAAB3N[blah blah blah]/UBR4= lanclos@lacquer.ucolick.org
Now that the files are in place, we need to insure that they have the correct permissions:
[lanclos@virgo]$ chmod 400 ~/.ssh/authorized_keys* [lanclos@virgo]$ chmod 700 ~/.ssh/ [lanclos@virgo]$ chmod g-w ~
That'll do it. The next time I attempt to log in from lacquer to virgo, I will be allowed access without entering my password-- assuming I have authenticated my keys with my ssh-agent, of course.
Additional information
If you would like to try other interesting tricks, we encourage you to read further in other online documents, such as Steve Allen's SSH page, or perhaps this lovely document on SourceForge. Or, if all else fails, you could always ask Google.