User Authentication Policies

Users of the Argonne BG/P systems are required to authenticate via SSHv2 keys or CRYPTOCard one time passwords.

This document explains the policies users must follow regarding SSHv2 keys and CRYPTOCard tokens for accessing the Argonne BG/P resources.

SSH

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 BG/P systems.

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, French, Japanese, 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) a "finger " command; b) looking in your .plan, .project, or other public files; c) 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.

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

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

NEVER GIVE YOUR PASSPHRASE TO ANYONE! Never tell anyone over the phone your passphrase or password. Nobody from ALCF 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 at alcf.anl.gov. If you receive electronic mail (email) from someone requesting your passphrase or password (including support@alcf.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

Summary

Protecting your SSH private keys is important:

  • Set permissions so that only you have read/write access (i.e. chmod 600 <privatekeyfile> ). If you are a Cygwin user, please read the note about CygwinFilePerms Cygwin unix file permissions section further down in this document.
  • Try to store your keys 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 store your keys 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.

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 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 man page [1]

Using SSHv2 key pairs
When you use a passphrased SSHv2 key the SSH client will prompt you for your passphrase. This passphrase is used on your 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 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 BG/P are available here.

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 man page [2].

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.

Note on Cygwin file permissions
Cygwin can emulate Unix-like file permissions but the feature is not enabled by default. One has to add "ntea" to the CYGWIN variable in the cygwin.bat file in the cygwin root directory, which tends to be C:\cygwin.
For example:

set CYGWIN=tty ntea

	in C:\cygwin\cygwin.bat.

With this,

chmod 0600 ~/.ssh/id_rsa

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

CRYPTOCard Tokens

Your CRYPTOCard token should be protected by you as carefully as your credit cards or house keys. If your token is lost, stolen, or damaged, please contact us immediately so that we can deactivate the token and prevent unauthorized access. Sharing of tokens is strictly forbidden. Please do not mark on the token or alter it in any way.

When you receive your token, it will be initialized, but it will have no access privileges until you have contacted us to verify your identity and that you have received the correct token.

At the end of your account or project lifecycle, please return the token to the ALCF help desk:

ALCF Service Desk
Argonne National Laboratory
9700 South Cass Avenue
Building 240
Argonne, IL 60439