Setting up SSH Keys for AGLT2

SSH is able to use a variety of methods for authenticating users. Each method has security strengths and weaknesses. The normal username/password authentication is pretty secure --- the password is encrypted before sending across the network to the remote host --- but it does send the password to the remote host and this can be a weakness. The remote host might be compromised and recording the passwords it receives for instance.

SSH supports public key encryption for logins, referred to as "SSH Keys". In this method, you generate your own private/public key pair and place the public key on the remote host. You can then authenticate to the remote host through a mechanism that verifies you have the private key (see background information on public/private key encryption for more info --- this is the idea behind Grid certificates, web SSL authentication and many other authentication mechanisms). SSH Keys has the advantage that the remote host never receives (and can't "steal") the private key. This is the "magic" of public key cryptography --- you never have to reveal your private key to authenticate.

As part of our security plan, we require SSH Keys for some login connections to the cluster. Even if not required, users may find it more convenient to use than the usual username/password authentication.

It is very important that users use SSH Keys in a secure manor. You must encrypt your private key. Unfortunately, we can not verify that you have done so (though if you don't and your keys are compromised, we'll know!)


Key Generation

To generate new keys use the ssh-keygen command. It is very important to use a strong password for your private key!! I recommend the following syntax (change as appropriate for your use):
   ssh-keygen -b 2048 -t rsa -C "Shawn's keys generated July 2, 2016" -f ~/.private/.ssh/id_rsa

This will generate a 2048 bit RSA (v2) key. You should see something like:

[smckee@umopt1 ~]$ ssh-keygen -b 2048 -t rsa -C "Shawn's keys" -f ~/.private/.ssh/id_rsa
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /afs/
Your public key has been saved in /afs/
The key fingerprint is:
e0:30:4c:01:44:ff:07:ea:3f:48:29:65:68:67:73:76 Shawn's keys

NOTE: The above command doesn't seem to create the keys in the correct locations. What we want is the private key in ~/.private/.ssh/ and the publick key in ~/.ssh/ Then we can create a softlink in ~/.ssh for the private key in ~/.private/.ssh/

You will now have a public (~/.ssh/ and private (~/.ssh/id_rsa which is a soft link to ~/.private/.ssh/id_rsa) key pair. You can share and distribute your public key freely but the private one must be carefully protected. To distribute and use your public key, first read about protecting it and then see below under "Using SSH Keys".

warning Make sure ONLY you can read/access your private id_rsa file. See below for notes on NFS and AFS areas.

Protecting and Using SSH Keys

Change permission of your ssh key

Now that you have your keys you must make sure to protect them well. The private key is the critical one. If your home area (or ~/.ssh directory) is on a regular disk or on NFS is should be sufficient to make sure that it is protected as follows:

  • chmod 400 ~/.ssh/id_rsa
This will allow only your user id to read the file. Things are much trickier if your home area (or ~/.ssh directory) resides in AFS.

Using SSH Keys

Now that we have gone to all the trouble to setup SSH keys how should we use them? SSH keys can make accessing your remote accounts much simpler after a few simple steps. First you need to add your "public" key to the ~/.ssh/authorized_keys files of all remote systems you want to access. If you have a common HOME area this is trivial:

  • cat ~/.ssh/ >> ~/.ssh/authorized_keys
This will append (or create if it doesn't exist) you public key to the list of authorized keys for your account.

Now try to login to a remote node via ssh which has an updated authorized_keys file. It should prompt you for the password you assigned to the private key. Then you should be logged in.

Note that if you need AFS rights, you'll still need to authenticate once logged in:

(provide password)


What happens when things don't work? The first thing to try is to add some feedback for the ssh command. Try:

ssh -vvv host

(Where host is the machine you are trying to SSH into).

The output is extensive but usually will indicate what the problem is.

Tips and Tools

If you don't like having to type your password a lot have a look into setting up and using ssh-agent. See ssh-agent visual information or Using ssh-agent. There is also a good section on this in "Linux Server Hacks V1".

For Windows users we strongly recommend getting and using PuTTY. You can get info and download it at PuTTY Info. One note about PuTTY. You will need to "convert" your private key to *.PPK for use in PuTTY. Run the PuTTYgen program, import your key and then save the private key back to disk with a .ppk extension. You can then use it in PuTTY. Also be sure to try out the pageant (like "ssh-agent" above) to manage your keys.

Step by Step Putty and Pageant setup
  1. Download Putty installer from here and install:
  2. Open PuttyGen from start menu
  3. Change "Number of bits in generated key" to 2048 and use type SSH2-RSA or SSH2-DSA
  5. See previous step.
  6. Click "Generate" and then "Save private key" - save in a convenient spot you will be able to remember. If you wish to use the same key for OpenSSH in cygwin, choose to "export OpenSSH key" from "Conversions" menu and save in your cygwin home under .ssh/id_rsa (or id_dsa).
  7. PuttyGen will display the public key for pasting into an OpenSSH authorized keys file. Copy this text and paste into ~/.ssh/authorized_keys in your AFS home directory. You can always get it back by opening PuttyGen and loading the .ppk file saved in previous step. umt3int01/02/03 allow password logins so you can access your AFS directory to paste the key.
  8. Open Pageant from the Start menu. An icon will appear in the system tray. Right-click on it and choose "new session". You can also add sessions by opening "!Putty".
  9. OPTIONAL: Any of the following information can be made default for all new sessions by clicking on "Default Session", then "Load". After setting options, return to "Session" and "Save" the Default Session.
  10. Enter the host name of the system to log into. Also enter a name for the session in the box under "Saved Sessions".
  11. Navigate to Connection->Data and enter an auto-login username (your username).
  12. Navigate to SSH->Auth and browse/enter the private key (.ppk) file created earlier in the box "Private key to use for authentication".
  13. OPTIONAL, RECOMMENDED: Under SSH->X11 check "Enable X11 Forwarding". Cygwin ( includes an X11 server - be sure to install package "x-start-menu-icons" to get a convenient shortcut to it.
  14. Return to Sessions and click "Save" to save these settings. At this point you should be able to login with a key but will be asked for the passphrase every time.
  15. Right-click again on the Pageant icon in your system tray. Choose "Add key" and open the .ppk private key file generated earlier. It will ask for your passphrase.
  16. From this point on, any Putty sessions configured to use this key will use the stored key and stored passphrase in Pageant as long as it is running
See also information on using a stored session for SVN access with TortoiseSVN.

Hints for PuTTy setup:
  • Connection->data add your username
  • SSH->Auth to select your .ppk key
  • SSH->X11 to enable X11 forwarding
With the versions of PuTTY and Cygwin available in July of 2015, there are two further changes required before PuTTY X-Windows will properly display. The changes are documented in these 2 URL: The gist of this is that 2 changes are required, one in Cygwin, one in PuTTY. For Cygwin, there are two options presented to change the way the X-server starts. Easiest is to do the following.
  • In the shortcut to start the server, the last of the commands should be: /usr/bin/startxwin -- -multiwindow -listen tcp
For the PuTTY change you need to know your Cygwin home directory, so in the session setup for PuTTY go to the Category SSH --> Auth --> X11 section, and enter your X authority file for local display, eg,
  • C:\cygwin64\home\your_pc_user_name\.Xauthority

Commercial SSH implementations

  • One example is the Windows client available at UM, may apply to other commercial implementations. In some ways this is a more convenient client than Putty so we would not discourage its use - UM users please contact OCS and they can install it (Ben can install it also). A major flaw is that it lacks any kind of agent to store keys as far as we are aware. It also sometimes has issues with large SCP transfers. The major redeeming feature is the GUI which you may or may not prefer over Putty, however Putty gives more functionality in general and is the de-facto Windows ssh standard client.
  • ssh-keygen can convert the public key generated from these clients so it is readable by OpenSSH servers - example below:
     ssh-keygen -i -f >> authorized_keys 
  • PuttyGen can export a compatible private key. Use menu item "Conversions->export". The public key format is supposed to be compatible.
  • To generate or load a keypair, open the Edit->Settings menu and navigate to User Keys. You can import the keyfile exported from Putty here to use the same key. OR you can generate a new keypair and convert the public key as noted above. You can copy the file by clicking "Upload Public Key" or use Window->New File Transfer from the ssh terminal window once you are connected. You can also paste directly from the "View Public Key" window if you know what to skip.
    Skip this part:
    ---- BEGIN SSH2 PUBLIC KEY ---- Comment: "[1024-bit dsa, bmeekhof@WALDO, Tue May 17 2011 02:10:26]" 
    Paste this part:
    AAAAB3NzaC1kc3MAAACBAL1ahL0C5Cu/TOAxhHnw16Nts40x1MkOhHgXFCc5DvuBSW1ocd .... rest of key ... PDpV6ezlASVUG9q7P18= 
    Skip this part:
    ---- END SSH2 PUBLIC KEY ---- 
-- ShawnMcKee - 01 Jul 2008
Topic revision: r23 - 06 Feb 2020, ShawnMcKee
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback