UC/ANL SSHv2 Key Creation and Usage Guidelines:

This document explains the procedures users must follow when creating, storing, and using SSHv2 keys for accessing UC/ANL TeraGrid resources.

Creating SSHv2 Keys

Summary:

• SSHv1 keys are not permitted.
• SSHv2 RSA and DSA keys are allowed.
• SSHv2 keys must contain at least 2048 bits.
• SSHv2 keys must have a strong passphrase (details below).
• Keys should be generated on a known to be secure machine.

Explanation:

The ability to crack SSHv2 keys depends directly on the type of key, the number of bits in the key, and the strength/quality and secrecy of the passphrase. The above guidelines are intended to minimize the risk of compromise if someone obtained a copy of your keys or was able to intercept your SSH session.

SSHv2 passphrases

Summary:

• SSHv2 keys must have a strong passphrase that:
1. Is NOT a word in any English, German, Frech, Japanene, or other dictionary
2. Is NOT a proper name, brand name, foreign name, or other name
3. Is NOT a word or set of words obtainable by:
   • a "finger " command,
   • looking in your .plan, .project, or other public files,
   • looking at any of your public web pages.
4. Is NOT be a word followed by a number.
5. Is NOT a reversed version of any of the above.
6. Is NOT an address (9700S.Cass).
7. Is NOT derived from a single word (He77o).
8. Should be at least 8 characters long.
9. Should contain mixed case letters, digits, and special characters.
• Should be kept secret and NOT written down anywhere.
• Should NOT be used as a password anywhere else, or as passphrases to other SSH keys.

Explanation:

Failure to comply with the strong passphrase guidelines may make your passphrase guess-able by people who a resourceful in finding information about you, or crackable using commonly available cracking software.

Suggestions for creating a secure passphrase:

• Embed extra characters in a word, especially non-alphabetic.
• Use unusual capitalization (all lower case is not unusual).
• Concatenate two or more words or parts of words.
• Interleave two or more words: for example "cdaotg" (but do not use this example!). If you need a one-second delay between characters as you type such a passphrase, don't use them.

Storing SSHv2 key pairs

Summary:

Protecting your ssh private keys is important:

• Set perms so that only you have read/write access.
• Try to only have them on a single machine that is locked down very tightly (i.e. no remote access allowed, no sshd, ftpd, telnetd, etc running), firewall protected, up-to-date on all security patches, including kernel patches.
• Try not to have them on an nfs mounted file system

Public keys don't need to be protected:

• May be copied to other machines.
• May have permissions that allow others to read it.
• The authorized_keys file should have permissions of 600.

Explanation:

Security of SSH keys depends on keeping both the private key and the passphrase secret. The best way to keep the private key secure is to store it on known to be secure machines like a personal laptop or workstation. When a machine is compromised the private keys on that machine are available to the hacker. It's very important to keep your private keys on as few machines as possible, to pick the most secure machines possible, and to avoid whenever possible storing them on machines and file-systems available to many users.

Using SSHv2 key pairs

When you use an passphrased SSHv2 key the ssh client will prompt you for your passphrase. This passphrase is used on you local machine to decrypt your private key so it can be used to connect to the remote machine. The private key never leaves the client machine (in encrypted or decrypted form).

For the remote machine to accept a connecting it must have your public key. Your SSHv2 public keys should be stored in the ~/.ssh/authorized_keys file.

To create this file use the commands:

• mkdir ~/.ssh
• chmod 700 ~/.ssh
• touch ~/.ssh/authorized_keys
• chmod 600 ~/.ssh/authorized_keys

You can add your public key to the authorized_keys file using an editor.

If you ssh many times and you wish to avoid typing in the passphrase every time, you can use an ssh-agent. For more information read the ssh-agent man page. An ssh-agent allows your client machine to keep a decrypted form of your ssh private key in memory for use when ssh'ing to multiple machines.

You may use ssh-agent forwarding when connecting thru one machine to another machine. But, because of security issues, you should only enable agent forwarding for connections where you will need it.

Additional information

Question regarding these guidlines should be e-mailed to help@teragrid.org and should indicate that they are regarding "SSH key guidelines on the UC/ANL cluster".