To get your OpenSSH keys set up, do the following:
- Create your SSH Keys - From a command prompt run:
ssh-keygen
This will prompt you for the key name and path and you are
encouraged to accept the default name of id_rsa
by just hitting Return/Enter when prompted. You will
also be prompted
for a passphrase that will be used to generate your public
(~/.ssh/id_dsa.pub) and private
(~/.ssh/id_dsa) SSH DSA keys. You are strongly encouraged not
to use an empty passphrase. Treat your SSH passphrase with the same
level of confidentiality that you do with your account
password. The passphrase you enter will be used to login to
your account and to load your keys using ssh-add (as described below).
See the ssh-keygen man page for more details.
- Create your authorized_keys file- This file
lists the public keys that can be used to log into
your account. This file is not required in order to
use OpenSSH, but it allows you to access various
systems by loading your SSH key one time and then
not being prompted for a password with each login.
This is particularly useful if you are running
processes on a number of machines via ssh and don't
want to be continuously prompted for a password.
This file is ~/.ssh/authorized_keys
and just contains the public keys you want to
authorize for access to your account. You can create
this file by simply running:
cat ~/.ssh/id_dsa.pub> ~/.ssh/authorized_keys
Once your keys are set up, you can use ssh several ways.
For example, on the Linux machines your desktop
sessions run under
the ssh-agent, which manages your ssh keys. Once you have
an ssh key loaded, it is available for all windows in your
entire login session. To take advantage of this, you can
do one of the following:
- Once you login, get a terminal window and run ssh-add.
This will prompt you for your ssh passphrase and load
your key for this session. Once this is done, you should
be able to ssh into any other system that has the same
authorization key without having to enter a password.
This should work when logged into the console of any
the CS Linux machines
since they run under the ssh-agent by default. However,
if you try this and get:
% ssh-add
Could not open a connection to your authentication agent.
then your session is not running under the ssh-agent. You
can get around this by restarting a new shell under the agent
by running:
exec ssh-agent bash
where you can replace bash with the shell of your choice.
Once you do this, you should be able to run ssh-add to
load your key for that shell.
- Under Linux with Gnome, you can set things up so that you are prompted for your passphrase
when you login. To do this, follow these steps:
- Under the Systems menu, go to Preferences/More Preferences/Sessions
- From the Sessions configuration select the Startup Programs tab.
- Click the Add button to add a new startup program.
- Enter the Startup command of "ssh-add" and click OK.
Once this is done, you should receive a window upon login prompting you for your ssh passphrase.
If you want to set up ssh authentication on a remote system
that is also running OpenSSH
so you can ssh or scp to it without having to enter a password,
you will have to create a ~/.ssh directory on the remote system
and copy your authorized_keys
file from your CS account over to the remote system. Note that
in order for this to work, the remote system must also be
running the OpenSSH daemon. Many UITS systems
are running OpenSSH so everything should
work once you have copied your authorized_keys file over.
Note that systems running OpenSSH may be configured such that
they look for an authorized_keys2 file in addition to,
or instead of, the authorized_keys file. So, if you have
trouble getting things to work, try renaming or copying
authorized_keys to authorized_keys2 on the remote system.
If the remote system is running the ssh server from ssh.com,
you should see
the OpenSSH-SSH FAQ page for
instructions on getting ssh to work between CS and the remote
systems without having to enter a password.
If you run into trouble getting ssh authentication to work,
you may want to try using the -v flag to ssh for clues. For
example, you can get detailed debugging information about
the connection to steel by running "ssh -v steel".
Troubleshooting
If everything is working properly, when you ssh to another system
you will either 1) not be prompted for a password or passphrase
at all if you have your key loaded or 2) if you don't have your
key loaded, you will be prompted for
your passphase like this:
% ssh burrow
Enter passphrase for key '/u/robh/.ssh/id_dsa':
At this point, you would just enter your ssh passphrase and get
logged in.
The most common problem people have with this
is that their ssh does not have access to the private key that
corresponds with the public key that was added to the authorized_keys
file. The symptom of this condition is that you see a password
prompt instead of a passphrase prompt as follows:
% ssh rainier
robh@rainier's password:
Common causes of this include:
- When you created your keypair using ssh-keygen, you gave
a filename or path for the keys other than the default
and ssh can't find them. You can either re-run ssh-keygen
and accept the default filename and location or you can
specify an alternate path to the identity file using the
IdentityFile directive in your ~/.ssh/config file (see
the ssh_config man page for details).
- You are sshing from a system where the private key file is not
accessible. For example, if you are sshing from your home
system and you haven't copied over the private key to this
system. The quickest workaround for this is to first log
into some other CS or Extreme system and then ssh from there.
- You are sshing to a system that doesn't have access to your
authorized_keys file. For example, if you have an RI
cluster account it has a separate home directory from your
CS account. So, you will have to manually copy the
~/.ssh/authorized_keys file to the remote system. Note that
the remote system does NOT need access to your private
key, just the public key has to be in the authorized_keys file.
