Main

How to use BGL

SSH Policies on BGL

This document explains the policies users must follow when creating, storing, and using SSHv2 keys for accessing the Argonne BGL cluster.

SSHv2 keys

Summary:

• SSHv1 keys are not supported, therefore v1 keys are unusable.
• SSHv2 RSA and DSA keys are allowed.
• SSHv2 keys must contain at least 2048 bits, we prefer 4096 bits.
• SSHv2 keys must have a strong passphrase (details below).
• Keys should be generated on a known secure machine.
• Private keys should not be stored on the BGL cluster.

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

• 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. Is a long passphrase, must be longer than 8 characters. SSH PassPhrases can be made up of several words or character strings. Unlike traditional unix passwords that are limited to 8 characters, these can and should be much longer. However, it should not be so long that you are unable to type it correctly multiple times.
  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.

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

You should NOT use the passphrase to your BGL SSH key(s) as a password on any other machines. If you share passwords or passphrases between resources and one resource is compromised and passwords or passphrases are stolen, they could be used to compromise BGL.

If you learn of a security compromise at a remote site where you have an account please notify support@bgl.mcs.anl.gov.

NEVER GIVE YOUR PASSPHRASE TO ANYONE! Never tell anyone over the phone your passphrase or password. Nobody from MCS or Argonne BG/L will ask for your passphrase or password over the phone. (We can access your account without it. System administrators never need to know your passphrase or password.) If someone calls you and asks for your passphrase or password, please report this by sending mail to support@bgl.mcs.anl.gov. If you receive electronic mail (email) from someone requesting your passphrase or password (including support@bgl.mcs.anl.gov and root), please inform us immediately.

NEVER WRITE YOUR PASSPHRASE OR PASSWORD DOWN. Make your passphrase unique but something you can remember so you don't have to write it down. Having a longer passphrase can help you remember it. If the piece of paper you write your passphrase down on is stolen, your SSH keys could be compromised.

Storing SSHv2 key pairs

Protecting your ssh private keys is important:

• Set perms so that only you have read/write access (i.e. chmod 600 <privatekeyfile> ). If you are a Cygwin user, please read the note about Cygwin unix file permissions at the bottom of this page.
• 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.
• We recommend that authorized_keys file have permissions of 600.

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 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.

If you wish to be even more secure, you can keep your keys on external media, such as a USB memory stick. Then when you wish to log onto a remote computer, mount the external media on your local system, add the key to your ssh-agent with a very short timeout (1 minute is reasonable), unmount the external media and open the connection to the remote system. This allows you get access to the remote system while keeping your private key virtually inaccessible to any remote hacker. For information on using ssh-agent read the ssh-agent section of the 'Setting up SSH on BGL' document or read the ssh-agent man page.

Using SSHv2 key pairs

For the remote machine to accept your ssh connection it must have your public key. Your SSHv2 public keys should be stored in the ~/.ssh/authorized_keys file. Instructions for setting up your keys on BGL are available at http://www.bgl.mcs.anl.gov/bgl/Documentation/General/sshkey.php.

If you ssh many times and you wish to avoid typing in the passphrase every time, you can use an ssh-agent. 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. For information on using ssh-agent read the ssh-agent section of the 'Setting up SSH on BGL' document or read the ssh-agent man page.

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 and shutdown the connection as soon as you are finished using it.

Additional information

Note on Cygwin file permisssions

For example:

set CYGWIN=tty ntea

chmod 0600 ~/.ssh/id_rsa

You should also restrict access to your cygwin directory under windows to yourself and your system administrators only.

Last Updated: 4/28/2004 As of Monday, April 26th, you will need to be onsite or using the VPN for the above command to work. If you are not, please visit https://www-accounts.mcs.anl.gov/account.php and upload your public key and call the Help Desk at (630) 252-6813 to have that key moved to your authorized_keys file.