Read this first

If you are just looking for a way to not have to enter your TOTP 6-digit code so often, this is not the page for you. You should read this page instead.

Unattended logins are only necessary in rare cases where a human is not available to enter passwords and TOTP codes. A few examples:

• Automated transfers of data from a data source (microscope, particle accelerator, ...) to the cluster for processing.

• A centralized job scheduler that automatically submits and manages HPC jobs on multiple clusters.

Also, before using unattended logins to the NSC cluster, consider if you can instead:

• Pull the data from the NSC cluster (e.g from a batch job or a cron job on the login node)

NSC clusters that are not using two-factor authentication

For clusters not using two-factor authentication, you just add your SSH public key to the file ~/.ssh/authorized_keys and you will be able to login to the cluster without entering a password.

NSC clusters that are using two-factor authentication

Until you have enabled 2FA for your account, nothing will change.

Once you have enabled 2FA for your account, you will need to use it for all logins to the cluster. You can use either password + TOTP or an SSH key (in ~/.ssh/authorized_keys) + TOTP.

If you have a need for unattended logins, you must use SSH key login, and you must place the public key used for unattended logins in the file ~/.ssh/authorized_keys_unattended on the cluster. To then use unattended login, point the ssh-client to the unattended-URL of the cluster you want to connect to. For example: ssh x_examp@duolith-unattended.nsc.liu.se

Note: you can not use Thinlinc through the unattended login method.

Note: do not use the unattended feature just because it is convenient. We will review all unattended keys on a regular basis and you will be required to motivate why you need it as well as add restrictions on the key (e.g on IP address) to make it more secure.

Making your unattended logins more secure

An SSH private key that can be used to login "unattended" is of course more sensitive than one that also requires two-factor authentication to login.

Therefore we recommend the following:

• If you are not actively using unattended logins, the file ~/.ssh/authorized_keys_unattended should be removed. Guideline: if you are not using unattended logins at least monthly, remove the key. You can always add it back later when you need unattended logins again.

• A private SSH key (i.e the file that is on your computer) that can be used for unattended logins should whenever possible be stored encrypted on disk, preferably using the passphrase feature built into SSH (where the key is decrypted and made available to an SSH agent (see "Using an SSH agent" on https://www.nsc.liu.se/support/security/). If the passphrase feature cannot be used, the disk that the key file is located on should be encrypted. If this is not possible, contact NSC to discuss your options.

• If possible, the public key placed in ~/.ssh/authorized_keys_unattended should be limited, e.g to one or more IP addresses or to running a specific command. If you cannot add any such limit, contact NSC to discuss your options.

Limit from where you can do unattended logins

Most workflows requiring unattended logins will login from one or more known hosts (e.g another cluster or some facility that generates data to be automatically analyzed on the cluster). In this case it should be possible to limit which IP addresses the key can be used from.

To add such a limit to your key, add "from=..." to the beginning of the line in ~/.ssh/authorized_keys_unattended.

E.g

from="130.236.123.18" ssh-rsa AAAAB3NzaC1yc2[...]+KPL/0= my_somelab_unattended_key

Note: you can use both IP addresses and hostnames, and you can add multiple addresses (comma-separated) and wildcards. See the authorized_keys man page (man authorized_keys) for more information.

To find out which IP you are connecting from, you can e.g look at the environment variable $SSH_CLIENT when logged into Tetralith (i.e `echo $SSH_CLIENT`).

Limit which command can be executed

You can limit a public key to executing a single command. This can be useful if you e.g use an unattended login to check queue status on the cluster.

E.g

command="/usr/bin/squeue" ssh-rsa AAAAB3NzaC1yc2[...]+KPL/0= my_somelab_unattended_key_squeue
command="/usr/bin/projinfo" ssh-rsa AAAAF2Unkfasf[...]+KPL/0= my_somelab_unattended_key_projinfo

In the above example, squeue is run if you use one private key to connect and projinfo if you use another private key.

If you want a more flexible setup, you can let the command be a script that looks at the environment variable $SSH_ORIGINAL_COMMAND and decides what to do based on that.

Example script that can check the Slurm queue or submit a batch job:

#!/bin/bash
#
case "$SSH_ORIGINAL_COMMAND" in
    squeue)
        $SSH_ORIGINAL_COMMAND
        ;;
    sbatch*)
        echo "Simulating job submission: $SSH_ORIGINAL_COMMAND"
        ;;
    *)
        echo "Unsupported command $SSH_ORIGINAL_COMMAND"
        exit 1
        ;;
esac

Matching authorized_keys_unattended entry:

command="/home/x_examp/bin/my_unattended_wrapper" ssh-rsa AAAAB3NzaC1yc2[...]+KPL/0= my_somelab_unattended_key_projinfo

You can then run ssh x_examp@tetralith-unattended.nsc.liu.se squeueto see the queue and ssh x_examp@tetralith-unattended.nsc.liu.se sbatch ... jobscript.sh to submit a job, but the key cannot be used run run arbitrary commands.