Systems  
Status displays
System status
Retired systems
 
 
 
 
 
 
 
 
 
 
 
 

Security

Normally, NSC systems are accessed remotely through SSH (Secure Shell). This protects your communication from eavesdroppers. However, you can still make mistakes (e.g. using a weak password) that expose both you and NSC to unnecessary risks.

Pick a good password

When you receive a account on an NSC system, you are asked to set a new password on it. Please follow these two rules when choosing your password:

  • The password should be unique. Do not re-use a password you have ever used on another account.
  • Don't use an existing word, or a combination of existing words, i.e. anything that you can find in a dictionary or in Google. This also includes simple spelling variations: neither password, passw0rd nor password2009 are good passwords.

Tip: Pick a sentence that is easy to remember, and use the initials of the words as your password. Make sure it is at the very least eight characters long. For example, the Shakespeare quote "Three score and ten I can remember well" yields the password Tsa10Icrw. (But please don't use Tsa10Icrw as your real password, since you now can find it in Google...)

Tip 2: Even better, use a truly random password. For example, on most Unix-like systems you can run the command openssl rand -base64 12 to print a random sixteen character password.

Tip 3: By all means, write your password down. It is better to have a strong password written on a piece of paper in your wallet than to have a weak password that you can remember in your head.

Damage control

When a system is compromised and passwords stolen, the thing that causes the most grief is when the stolen password can be used for more than one system. A user that has accounts on many different computers and gets his/her shared password stolen will allow the intruders to easily cross administrative domains and further compromise other systems.

To login to a system and then continue from that system to a third (as illustrated below) should be avoided.

login_recommendation

Detect and report suspicious activity

When logging into a system, please read the "last login" information and verify that it matches your last login to the system. If it does not match, someone else might be using your account.

Example:

$ ssh x_makro@neolith.nsc.liu.se
x_makro@neolith.nsc.liu.se's password: 
Last login: Wed Apr 28 10:36:09 2010 from ming.nsc.liu.se
Welcome to Neolith!

/Neolith admin, support@nsc.liu.se
[x_makro@neolith1 ~]$ logout

If you can't verify the information or for some other reason suspect that someone else is using your account, YOU MUST contact support@nsc.liu.se as soon as possible.

Checklist:

  • Use different passwords for different systems.

  • Do not use weak passwords.

  • Avoid chains of SSH sessions.

  • Check: “Last login: DATE from MACHINE”

Making life easier with public keys

There is an alternative to traditional passwords. This method of authentication is known as key-pair or public-key authentication. While a password is simple to understand (the secret is in your head until you give it to the ssh server which grants or denies access), a key-pair is somewhat more complicated.

A key-pair is as the name suggests a pair of cryptographic keys. One of the keys is called the private key (this one should be kept secure and protected with a pass phrase) and a public key (this one can be passed around freely as the name suggests).

After you have created the pair, you have to copy the public key to all systems to which you wish to establish a ssh-connection. The private key should be kept as secure as possible and protected with a good pass phrase. On your laptop/workstation you use a key-agent to hold the private key while you work.

Pro
  • Can be much more secure than regular password authentication.

  • Can be less secure if used incorrectly (understand before use).

  • Allows multiple logins without reentering password/pass phrase.

  • Allows safer use of ssh chains.

  • Enables message passing (with e.g. MPI and Linda) between nodes.

Short description of SSH public-key authentication

(see also Chapter 4 in SSH tips, tricks & protocol tutorial by Damien Miller)

  1. Generate a key-pair on your computer. Choose a good passphrase, and make sure the private key is secure (file permissions etc).

    Note: Except for certain very specific situations, having passphrase-less keys is an extremely bad habit. It's approximately equivalent to storing one's password in a plaintext file called "HERE_IS_MY_SECRET_PASSWORD.TXT". Only slightly worse. All passphrase-less keys found on NSC systems will be immediately deleted.

    Example of key generation using ssh-keygen (OpenSSH):

    $ ssh-keygen
    Generating public/private rsa key pair.
    Enter file in which to save the key (/home/kronberg/.ssh/id_rsa): 
    Created directory '/home/kronberg/.ssh'.
    Enter passphrase (empty for no passphrase): 
    Enter same passphrase again: 
    Your identification has been saved in /home/kronberg/.ssh/id_rsa.
    Your public key has been saved in /home/kronberg/.ssh/id_rsa.pub.
    The key fingerprint is:
    57:09:b4:af:77:9c:82:7f:90:09:70:35:a8:90:84:6c kronberg@ming
    The key's randomart image is:
    +--[ RSA 2048]----+
    |   . o.. .ooo    |
    |    E o . oo o   |
    |   .   . +. o    |
    |        . .o     |
    |        S ...o   |
    |         . o+. . |
    |          o o.+  |
    |           o o.  |
    |            ..   |
    +-----------------+
    $ 
    
  2. Put your public key into the file ~/.ssh/authorized_keys on desired systems. (The script ssh-copy-id can help with this, see the example below or the man page for ssh-copy-id.

    $ ssh-copy-id x_makro@kappa.nsc.liu.se
    x_makro@kappa.nsc.liu.se's password: 
    Now try logging into the machine, with "ssh 'x_makro@kappa.nsc.liu.se'", and check in:
    
      .ssh/authorized_keys
    
    to make sure we haven't added extra keys that you weren't expecting.
    
    $ ssh x_makro@kappa.nsc.liu.se
    Last login: Wed Apr 28 14:17:06 2010 from ming.nsc.liu.se
    [...long login message...]
    [x_makro@kappa ~]$ cat .ssh/authorized_keys
    ssh-rsa AAAAB3[...long public key...]RP9ANrQ== my@key.id
    [x_makro@kappa ~]$ 
    
  3. Load your private key into your key-agent (ssh-add with OpenSSH). NSC recommends using "ssh-add -c" - This will ask for confirmation every time the key is used which increases security.)

  4. Run ssh, scp, or sshfs all you want without reentering your pass phrase, without the risk of anyone stealing your password. (If you used ssh-add -c as suggested above then you have to hit enter in the confirmation dialog every time your key is used).

    kronberg@ming:~$ scp somefile x_makro@neolith.nsc.liu.se:
    somefile                                      100%    0     0.0KB/s   00:00    
    kronberg@ming:~$ ssh -l x_makro neolith.nsc.liu.se
    Last login: Tue May  4 11:44:36 2010 from ming.nsc.liu.se
    
    Welcome to Neolith!
    
    /Neolith admin, support@nsc.liu.se
    [x_makro@neolith1 ~]$ 
    

    Note: many systems (e.g Ubuntu) will automatically load SSH keys when you login, so you will not have to do anything except enter your passphrase once the first time you try to use the key.

ssh-agent in Windows

Yes, this actually works just fine in Windows as well, using the Putty ssh client and the Winscp program. Putty has an agent program called "Pageant". On the page http://www.unixwiz.net/techtips/putty-openssh.html you can find instructions for creating a key-pair and setting up ssh agent and agent forwarding.






Page last modified: 2011-03-04 11:05
For more information contact us at info@nsc.liu.se.