How do I set up my UNIX account for OpenSSH usage

http://www.phcomp.co.uk/TechTutorial/HOWTOs/ssh_passwordless_login.php
https://www.cs.indiana.edu/Facilities/FAQ/Security/openssh.html
CSG FAQ

Q: How do I set up my UNIX account for OpenSSH usage?

To get your OpenSSH keys set up, do the following:

1. 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 stronglyencouraged 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.
   
2. 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:

1. 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.
2. 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:
   
   
   
   1. Under the Systems menu, go to Preferences/More Preferences/Sessions
   2. From the Sessions configuration select the Startup Programs tab.
   3. Click the Add button to add a new startup program.
   4. 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 anauthorized_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 toauthorized_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.