You are here: Foswiki>AGLT2 Web>SetupSSHKeys (17 May 2011, BenMeekhof)EditAttach

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!)

References

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 1024 -t dsa -C "Shawn's keys generated July 2, 2008" -f ~/.ssh/id_dsa

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

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

You will now have a public (~/.ssh/id_dsa.pub) and private (~/.ssh/id_dsa) 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_dsa file. See below for notes on NFS and AFS areas.

Protecting and Using SSH Keys

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_dsa

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.

Protecting SSH Keys (or X509 Certificates) on AFS

This section applies to user's with home area in AFS In general, it applies to users at U-M, but not at MSU.

If you have private information stored in AFS areas you have to be very careful. Your local system will respect the file protections you set (via chmod) but other systems very well may not! AFS has its own methodology of protection information stored in AFS. Unfortunately AFS doesn't set protections (ACLs) on individual files but rather on directories. ACL stands for Access Control List.

To secure private keys (or X509 keys) in AFS you need to do some work. I recommend creating a new subdirectory in your home area (in AFS). Make sure you have tokens as your AFS user and create a new directory:

  • mkdir ~/.private
  • chmod -R 744 ~/.private

This will setup a "private" directory tree in your AFS home area. Now we need to protect it via AFS ACLs. You can use the fs listacl command to see the current protection:

[smckee@umopt1 ~]$ fs listacl .private
Access list for .private is
Normal rights:
  usatlas:umtestbed rlidwka
  system:administrators rlidwka
  system:anyuser rl
  smckee rlidwka

This is not what we want at all. We need to remove ALL other AFS user access except our own. To do this we specify our own desired ACL followed by the -clear option:

  • fs setacl .private smckee rlidwka -clear

This gives us:

[smckee@umopt1 ~]$ fs setacl .private smckee rlidwka -clear
[smckee@umopt1 ~]$ fs listacl .private
Access list for .private is
Normal rights:
  smckee rlidwka

Good! Now only we can see this directory. Also if we create any new subdirectories they will inherit the same AFS ACL (which is what we want). Lets make one to hold our private SSH key and move it there:

  • mkdir .private/.ssh
  • mv .ssh/id_dsa .private/.ssh/id_dsa

Last step is to link to this new location from the old one:

  • ln -s .private/.ssh/id_dsa .ssh/id_dsa

Make sure the unix file system protection is still 400:

  • chmod 400 .private/.ssh/id_dsa

That's it. Your key should be secured now and only useable by you. By the way, this also works well for X509 certs (just treat your .globus/userkey.pem as you did the id_dsa file)

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/id_dsa.pub >> ~/.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:

kinit
(provide password)
aklog

Troubleshooting

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: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
  2. Open PuttyGen from start menu
  3. Change "Number of bits in generated key" to 2048 and use type SSH2-RSA or SSH2-DSA
  4. TYPE IN A PASSPHRASE.
  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 (http://www.cygwin.org) 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

Commercial SSH implementations
  • One example is the ssh.com 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 id_dsa_ssh2.pub >> authorized_keys
        
  • PuttyGen can export a compatible private key. Use menu item "Conversions->export ssh.com". 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: r19 - 17 May 2011 - 02:31:57 - BenMeekhof
 

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