Skip to content

Request Access

New users request access to MLCloud's resources through contacting the Group Managers of the user's research group. The Group Manager should then submit the request using the User Management System.

Once the request is processed, you will receive three emails

  • a welcome email
  • a password reset email
  • a one-time password to bypass our multifactor authentication once

Username Convention

To access the ML Cloud, you will receive a username with a format like pbb111. This naming convention, designed for GDPR compliance, ensures no personal information (like first and last names) is processed after user offboarding.

What if I no longer have access to the previous SSH keys?

Please send us a support ticket including your public key in an attachment to the ticket and we will deploy the key for you.

What if I no longer have access to my TOTP?

Please send us a support ticket.

First Time Login

At the ML Cloud, we do not allow logging into our systems solely with a password; rather, we require key-based authentication + TOTP.

Step One: Creating Your SSH Keys

It is important to generate a secure key pair. The current best key type is called Ed25519. Open a local Terminal window and run:

ssh-keygen -a 100 -t ed25519 -f ~/.ssh/id_ed25519
Then, enter a passphrase when asked. It needs to be entered in the future to unlock your private key.

The generated keys for ed25519 are stored in the following files:

Key Explanation
~/.ssh/id_ed25519 Your private SSH key that should be stored only on the machine it was created on. NEVER EVER TRANSMIT THIS FILE OFF ITS ORIGINAL COMPUTER.
~/.ssh/id_ed25519.pub Your public SSH key. This file is the ONLY one that is SAFE to distribute.

What do the options to ssh-keygen mean?

The options to ssh-keygen listed above specify the type of the key (-t), the number of key derivation function rounds (-a), and the location to place the key (-f), which is selected to be the default. To distinguish multiple keys, give a comment to the key with -C. If the file ~/.ssh/id_ed25519 already exists, you probably don't want to override it as you might already be using it as credentials for another system. Instead, use a different file name, e.g. ~/.ssh/id_ed25519_mlcloud and remember to use the same file name on all subsequent command lines in this document.

Your SSH private key should only ever exist on the computer it was generated on, and should never be moved to another computer.

Step Two: Add your Public Key to your profile in Coldfront

  1. Login to MLCloud portal

  2. At the top right , click on your profile name then User Profile

  3. Add your public ssh key in SSH public key field and click save wait for ~20 seconds.

You can find the key in ~/.ssh/id_ed25519.

On MacOS:

Add your SSH key to the system keychain, run ssh-add --apple-use-keychain ~/.ssh/id_ed25519.

Step Three: First connection and set-up

We will send you a confirmation email. Connect to galvani-login.mlcloud.uni-tuebingen.de or galvani-login2.mlcloud.uni-tuebingen.de.

ssh -i ~/.ssh/id_ed25519 username@galvani-login.mlcloud.uni-tuebingen.de

Enter the one-time password, that you received in the email before.

You will be prompted with a QR code for your autheticator app as well as a number of emergency codes. Follow the instructions on screen.

We recommend any TOTP-compatible authenticator app, such as Google Authenticator, Microsoft Authenticator, Authy, or a password manager with built-in TOTP support such as Bitwarden, 1Password, or KeePassXC.

You can now connect to all ML Cloud login nodes using your key and your TOTP.

How to add other SSH key pairs

If you want to connect from different machines, create a new key pair as explained above and add it as a new line to the ~/.ssh/authorized_keys file on every cluster you want to connect to (Galvani, Ferranti, ...). Make sure the permissions of the file are set correctly: 

chmod 600 ~/.ssh/authorized_keys

Or you can replace your ssh public in Coldfront profile with the new public key and click save, It will not remove your old key, You can use both keys.

Authenticating once: SSH connection multiplexing

With two-factor authentication enabled, every new SSH connection — including each scp, rsync, or scripted ssh call — normally asks for a fresh TOTP code. This breaks workflows that open many connections in sequence.

SSH connection multiplexing lets you authenticate once and then reuse that single authenticated connection for all further commands to the same host, with no additional 2FA prompts, until the connection expires.

How it works

An SSH connection can carry many independent channels (interactive shells, remote commands, file transfers) over one authenticated transport. Multiplexing makes your local SSH client share one connection instead of opening — and re-authenticating — a new one each time:

  1. Master connection. Your first ssh to a host performs the full handshake and the one TOTP prompt, then opens a local control socket.
  2. Persistence. The master stays running in the background for a configured time window, even after that first session ends.
  3. Client connections. Every later ssh, scp, or rsync to the same host detects the socket and runs as a new channel over the existing master connection. Because no new connection is established, no authentication — and therefore no 2FA code — is requested.
  4. Expiry. When the idle window elapses (or you close it manually), the master shuts down. The next connection authenticates again. Server-side we limit connections to be persistent for 12 hours.

Configuration

Add the following to ~/.ssh/config on the machine you connect from (your laptop or workstation), and create the socket directory once:

mkdir -p ~/.ssh/cm

Add the following section to your local ~/.ssh/config:

Host galvani-login* ferranti-login*
    ControlMaster auto
    ControlPath   ~/.ssh/cm/%C
    ControlPersist 1h
    User username
    IdentityFile ~/.ssh/id_ed25519
  • ControlMaster auto — reuse an existing master if present, otherwise become one.
  • ControlPath ~/.ssh/cm/%C — location of the control socket (%C is a short hash that avoids path-length problems).
  • ControlPersist 1h — keep the master alive for 8 hours of idle time.

Usage

Connect once to any login node interactively and enter your TOTP code:

ssh -i ~/.ssh/id_ed25519 username@galvani-login.mlcloud.uni-tuebingen.de

All subsequent commands to that login node reuse the connection without prompting for TOTP.

Managing the connection

ssh -O check galvani-login.mlcloud.uni-tuebingen.de   # is the master connection alive?
ssh -O exit  galvani-login.mlcloud.uni-tuebingen.de   # close it now (next login will prompt again)

Limitations

  • Same machine only. The control socket is local to the host that holds it. Automation running on a different machine cannot share it and will still need to authenticate.
  • Shared fate. All multiplexed sessions ride one transport; if the master connection drops, every session using it drops too.
  • Session limit. A single connection allows a limited number of concurrent channels (server default: 10).

Generate your QR code again

If you need to set up your authenticator app on a new device, you can regenerate the QR code from your existing secret by running the following command on any login node:

qrencode -o- -t ANSI256 -d 300 -s 10 "otpauth://totp/$USER@$(hostname)?secret=$(head -1 $HOME/.ssh/google_auth)"

Display the MFA recovery codes again

If you lost your recovery codes , you can display them again by executing the following command on any login node:

cat ~/.ssh/google_auth | tail -n 5
Last update: June 10, 2026
Created: June 21, 2024