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

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 also need to limit your unattended key, see “Making your unattended logins secure” below.

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 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 require that you do the following if you use the unattended option:

• If you are not actively using unattended logins, the file ~/.ssh/authorized_keys_unattended must be removed or renamed (so it’s no longer used). Guideline: if you are not using unattended logins at least every few days, remove or rename the key. You can always add it back later when you need unattended logins again.

• Any private SSH key (i.e the file that is on your computer) that can be used for unattended logins must 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 this page). If the passphrase/ssh-agent feature cannot be used, the disk that the key file is located on must be encrypted. If this is not possible, you may not use unattended logins unless you have got an explicit exception from these rules from NSC - contact NSC Support to discuss your options.

• The public key placed in ~/.ssh/authorized_keys_unattended must be limited, either to run a single command (the “command=…” option inside the key file) OR so logins are only possible from a limited number of IP addresses or hostnames (using the “from=…” option). Unless you have an explicit exception from this rule from NSC, you may not have more than five IP addresses or hostnames listed. Using wildcards is not permitted unless it’s obvious that the total number of matches is five or less. You may use multiple public keys in ~/.ssh/authorized_keys_unattended, but the total limit on IP addresses and hostnames is still five. If you cannot add any such limit or need more than five addresses listed, contact NSC to discuss your options.

HOWTO: 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). 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).

If you find that your IP address/hostname changes often, we recommend that you talk to your local IT support about getting a fixed IP address for your own computer or a virtual machine with a fixed IP on which to run your code.

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