Access and Environment

SSH Login

The Secure Shell (SSH) protocol is used to access interactive nodes on Mistral. SSH client programs are available for all major operating systems. To access one of the mistral login nodes youu can use the following command:

ssh -X <userid>

in which <userid> must be replaced by your individual user account.

After having logged into mistral, you will find yourself on one of the seven login nodes: mlogin[100-105,108]. The login nodes serve as an interface to the compute nodes of the HPC cluster. They are intended for file editing and compilation of source code, as well as for submission, monitoring and canceling of batch jobs. They can also be used for simple and none time and memory intensive serial processing tasks. The routine data analysis and visualization, however, have to be performed on mistralpp or on Mistral prepost nodes as explained here. For advanced 3D data visualization specialized visualization resources are provided. For interactive testing and debugging of parallel programs you can use SLURM salloc command to allocate the required number of nodes.


All DKRZ systems are manged by the LDAP protocol. The password can be changed through DKRZ online services. A user defined password must contain at least eight nonblank characters and has to be a combination of upper and lowercase letters, numbers and special characters. Additional checks are made to ensure that the password is no dictionary word and not too simple. The online service will give you detailed error messages if and why a new password was rejected.

In case you do not remember your password please request a password reset.

Public Key Authentication

The default password authentication is neither comfortable nor very secure. In order to use public key authentication, you have to generate a key pair and upload the public key to DKRZ. The command for key generation is ssh-keygen. It supports different key types. We recommend ed25519 keys.

ssh-keygen -t ed25519

Please use a strong passphrase to secure your key. By default, this created two files named id_ed25519 and

ls ~/.ssh/

The file ending with .pub has to be uploaded to First press “Add key”

upload a new public key

The public key can be selected from a file by pressing the “Browse” button or pasted directly into the Key input field. Do not select UFTP unless you want to use this key for UFTP exclusively. After pressing “Register key”, the key is uploaded to the server. In order to use it on mistral, you have to provide your LDAP password.

push new keys to LDAP

After that your key should be active and ready to use.

ready to use keys are indicated with a green icon

Key validity

For most key types, the validity or lifetime of the keys is six weeks. A longer lifetime is allowed for keys using hardware tokes (see below). You should receive an e-mail one day before the key expires. You then have to upload a newly created key to continue using public key authentication. The old key is blocked from further use at DKRZ and cannot be uploaded again.

Managing Multiple SSH Keys

You may require multiple SSH keys for different computer centers. Reasons for this are added security and the fact that policies for key properties and lifetime may differ from site to site.

To prevent your SSH client from trying out all available keys, you should tell it exactly where to use which key. For this purpose you can create or edit the configuration file in ~/.ssh/config.

Host *
     IdentityFile ~/.ssh/id_ed25519
     IdentitiesOnly yes

This tells ssh to use only the key ~/.ssh/id_ed25519 to log into any host at DKRZ.

Increased security and key lifetime with hardware authenticators

FIDO2 hardware key

OpenSSH starting with version 8.2 supports FIDO/U2F hardware authenticators or tokens. The use of such tokens increases the security of your ssh-key, as not only the key file (and passphrase) is needed for auth, but you need to touch the token when logging into a system. Because of the increased security, we allow a lifetime of 365 days for SSH keys which work in conjunction with such a token. There are two major requirements for the use of this technology:

  • A recent OpenSSH version, i.e. OpenSSH 8.2 or more recent.

  • A token.

We recommend you to ask your IT department for obtaining one. We recommend FIDO certified tokens, following the U2F or FIDO2 specification, with FIDO2 being more future-proof. At DKRZ, Yubicos YubiKey tokens have proven convenient. The cheaper Yubico “Security Key” model does the job.

Once you have the recent SSH client and a token, you need to create a new ssh-key of type ed25519-sk by running

ssh-keygen -t ed25519-sk

You can upload the public key to following the instructions provided above for classic keys. Do not select UFTP. You should notice the extended lifetime when you upload the public key. For authentication with mistral, the token has to communicate with your local device (via USB, NFC, etc.) and you have to touch it to confirm your presence.


Having two keys, one at your desk, one on your keychain/… has proven convenient. Each token needs a separate SSH key.

OSX: The openssh which comes along with MacPorts (here version 8.4, as of 30 Aug 2021) does not support fido2. A ssh (8.7p1) installed via brew does work.

Default login shell

The default login shell for new DKRZ users is bash. You can change your login shell to tcsh, zsh etc. using the DKRZ online services. The settings you would like to use every time you log in can be put into special shell setup files. A login bash shell looks for .bash_profile, .bash_login or .profile in your home directory and executes commands from the first file found. A non-login bash shell or bash subshell reads .bashrc file. Tcsh always reads and executes .tcshrc file (or .cshrc if .tcshrc is not found). If tcsh is invoked as login shell, file .login is sourced additionally. The typical tasks and setting that can be put in shell setup files are for example:

  • Creation of a custom prompt

  • Modification of search path for external commands and programs

  • Definition of environment variables needed by programs or scripts

  • Definition of aliases

  • Execution of commands (e.g. module load <modname>/<version>)

Primary group

Your primary Unix group will be set to the first project your account is member of. This will not be modified until the project expires. Even if you join other projects, the primary group will stay the same. If you wish to have a different primary group (e.g. you are working most of the time for a different project), you will have to contact DKRZ user’s consultancy, there is no option to change the primary group on your own.

Module environment

To cover the software needs of DKRZ users and to maintain different software versions, the DKRZ uses the module environment. Loading a module adapts your environment variables to give you access to a specific set of software and its dependencies. The modules are not organized hierarchically but have internal consistency checks for dependencies and can uniquely be identified by naming convention <modname>/<version>. Optionally, the version of the compiler that was used to build the software is also encoded in the modversion string (e.g. all modules built with version 4.8 of the GCC compiler are labeled with *-gcc48).


If only the <modname> (i.e. without <version>) is supplied, the latest installed software version (for which no bug is known) is loaded. If you want to make sure that the loaded module version is not changed within job chains, you must explicitly supply the <version>.

Users can load, unload and query modules through the module command. The most important module sub-commands are:

  • module avail: Shows the list of all available modules

  • module show <modname>/<version>: Shows the effect of loading the module <modname>/<version> on your environment

  • module load <modname>/<version>: Loads selected module; a default version is chosen, unless <version> is specified

  • module list: Lists all modules currently loaded

  • module rm <modname>/<version>: Unloads module <modname>/<version>

  • module swap <modname1> <modname2>: Switches loaded module <modname1> to <modname2> (mainly used to switch to a different version of software)

  • module purge: Unloads all modules

  • module apropos <keyword>: Scans the available module files for the specified keyword and list all matching modules

  • man module: Displays manual pages for the module command


Upon login to mistral the module defaults will be loaded for all users automatically. Herein are summarized several commonly used tools such as cdo or git. If you do not want to make use of this, you simply have to add the module purge command to your personal shell configuration file.

For all details of the module command please refer to the manual pages or execute module --help.

To use the module command in a script you have to source one of the following files before any invocation of the module command:

# in bash or ksh script
source /etc/profile.d/

# in tcsh or csh script
source /etc/profile.d/mistral.csh

The module avail command provides up-to-date information on installed software and versions. For a comprehensive list of software and tools available on Mistral, see our Software List.