Login Security

Normally, NSC systems are accessed remotely through SSH (Secure Shell). This protects your communication from eavesdroppers. However, you can still make mistakes (for example using a weak password, or using a password that is used for something else too) that expose both you and NSC to unnecessary risks.

Pick a good password

When you are about to receive an 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.

Many applications offer to save your password so you don’t have to remember it. Do not use this feature unless you have verified that it is reasonably secure (i.e not storing your password unencrypted on disk).

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.

Two-factor authentication

Some NSC clusters require two-factor authentication (“2FA”) to log in. You can read more about which clusters and how to use 2FA on this page.

To keep your 2FA TOTP codes safe:

• Only install trusted TOTP apps from trusted sources.
• Do not install the TOTP app on the same device you use to login to the cluster.

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 minimize risk, logging into one system and then continuing from that system to a another (as illustrated below) should be avoided.

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@tetralith.nsc.liu.se
x_makro@tetralith.nsc.liu.se's password: 
Last login: Wed May 20 15:30:52 2020 from mylaptop.example.org
Welcome to NSC and Tetralith!
...

[x_makro@tetralith1 ~]$ 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 SSH 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 on your local computer and protected with a pass phrase and will be called something like “id_rsa”) and a public key (this one can be passed around freely as the name suggests and will be called something like “id_rsa.pub”).

After you have created the key pair, you have to copy the public key to all systems to which you wish to establish SSH connections. The private key should be kept as secure as possible and protected with a good pass phrase.

On your laptop/desktop computer you use an SSH agent to hold the private key while you work, so that you do not have to enter the private key passphrase each time you login somewhere using SSH.

Things to consider:

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

Getting started with SSH public-key authentication

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

This tutorial assumes that you use a command-line SSH client (e.g OpenSSH) on your computer (i.e you’re using Linux or MacOS).

You can use public-key authentication from Windows as well, using e.g the PuTTY SSH client. The SSH agent in PuTTY is named Pageant. Please read the PuTTY documentation for more information. This tutorial might also be useful.

Generate a key-pair on your local computer. Choose a good passphrase¹ (just like you would choose a good password), and make sure the private key is secure (it should only be readable by you).

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:

[... removed for brevity ...]

$ 

Put your public key into the file ~/.ssh/authorized_keys on systems where you want to be able to login. (The script ssh-copy-id can help with this, see the example below or the man page for ssh-copy-id.

$ ssh-keygen
$ ssh-copy-id x_makro@kappa.nsc.liu.se
x_makro@kappa.nsc.liu.se's password: 

Now try logging into the machine. If the key has been correctly set up you will not need to use your password (but you will be asked for your passphrase at this stage):

$ 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 ~]$ 

Using an SSH agent

Load your private key into your SSH agent (ssh-add with OpenSSH). NSC recommends using “ssh-add -c” as this will ask for confirmation every time the key is used which increases security, especially if you go on to user agent forwarding below.

$ ssh-add -c
Enter passphrase for /home/someuser/.ssh/id_rsa: <enter your passphrase here>
$

You can verify using “ssh-add -l” that you key is loaded into the agent.

You should now be able to run ssh, scp, or sshfs without reentering your pass phrase and 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 once every time your key is used).

kronberg@ming:~$ scp somefile x_makro@tetralith.nsc.liu.se:
somefile                                      100%    0     0.0KB/s   00:00    
kronberg@ming:~$ ssh -l x_makro tetralith.nsc.liu.se
Last login: Wed May 20 15:30:52 2020 from mylaptop.example.org
Welcome to NSC and Tetralith!
...

[x_makro@tetralith1 ~]$ 

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.

Using SSH agent forwarding

There are situations where you need SSH access from one cluster to another. For example, you might want to login to one cluster and then copy files from there to another cluster using scp (that uses SSH connections below the surface).

If you have already started to use the SSH agent as shown above, you can then go on to use agent fowarding for this.

For this example, we assume that you have already set up so you can login using SSH public key authentication to both clusters.

Use the -A option when you login from your local computer the first cluster to signal that you want to enable agent forwarding. Then just use the scp command to copy files to to the second cluster.

When the scp commands tries to connect using SSH from the first cluster to the second one, the first cluster forwards the “please prove your identity” message from the second cluster to your local computer, where the SSH agent will be able to prove that you are you, and the answer then gets sent back via the first cluster to the second, who lets you access it. This is accomplished without your private key ever leaving your local computer.