This is the key to using the cluster effectively even after 2FA is needed to log in.
When you have configured SSH connection sharing, the first login you make to the cluster (after being fully disconnected) will become the “master connection”.
The next times you open an SSH connection (includes scp, sftp, rsync, …) to this host, the master connection will be re-used and you will not have to enter your password or TOTP code.
This works for as long as the master connection is alive. If you use the ControlPersist setting, the master connection stays open even if you close the initial terminal window.
However, if the TCP connection to the cluster is lost (e.g if your Internet connection goes down or you suspend your laptop), you will have to authenticate using TOTP again when you open the first SSH connection to the cluster.
Connection sharing is controlled by the settings ControlMaster
,
ControlPersist
and ControlPath
in your SSH client configuration
file ~/.ssh/config
on your local computer (no changes are needed on
the cluster).
Suggested settings (for the fictional cluster Duolith, add this to ~/.ssh/config on your local computer and replace duolith with the actual cluster name and x_examp with your own username.
Host duolith.nsc.liu.se
User x_examp
ControlMaster autoask
ControlPath ~/.ssh/cm-%r@%h:%p
ControlPersist 2h
User x_examp
is just for convenience - no need to enter the username
x_examp on every login.
ControlMaster autoask
will set the connection to become the master
if no master exists. Otherwise you will manually have to decide (ssh
-M
) which connection is the master. It will also ensure that SSH
opens a window asking “Allow shared connection to …?” every time a
new connection wants to use the existing login. This makes connection
sharing a little more secure, as it becomes more difficult for someone
that can access your account on your own computer to start a new SSH
connection through the existing login. If you do not want this extra
layer of security, replace “autoask” with “auto”.
Please note that autoask
requires that the ssh-askpass
command is
installed.
ControlPath ~/.ssh/cm-%r@%h:%p
means that the socket used to share
the connection is placed in that location, e.g
~/.ssh/cm-x_examp@duolith.nsc.liu.se:22. It is important that this
socket is placed in a secure location where other users cannot access
it.
ControlPersist 2h
means that even if you close the first (master)
terminal window, the master connection stays alive in the background
for 2 hours even if there are no new connections using it.
The OpenSSH client shipped with Windows 10 does not appear to support connection sharing. You can use PuTTY instead (you can then open more PuTTY terminal windows and transfer files using pscp and psftp without entering your password and TOTP code again).
It’s possible that the OpenSSH in Windows Subsystem for Linux (WSL) can use connection sharing.
If you prefer using an SSH key instead of a password as the “first factor”, you can do so. Place the public key in ~/.ssh/authorized_keys as you would normally do. You will then only be asked for the TOTP code on login (but your SSH client must of course have access to the private key).
This can be combined with SSH connection sharing.
Fully unattended logins are difficult to combine with 2FA, since there is no one around to enter codes from an app. In theory, a hardware 2FA key that does not require pushing a button could be used, but that is not something we support today.
Fully unattended logins are still possible even on NSC clusters using 2FA, but they will become more restricted in the future, e.g requiring specific approval or being limited to a single IP address.
Therefore we do not recommend that you start using this method for “ordinary” logins. If you e.g have a script that runs on your laptop and logs in to the cluster every 5 minutes to check on your jobs, you do not need fully unattended logins for that. You can just use SSH connection sharing, and as long as your master connection is alive, your script will run just fine.
Please read this page for details on unattended logins and how they might change in the future.
In theory, it should be possible to trick the built-in SSH client in the Thinlinc client to use the SSH connection sharing of your regular SSH, but I wasn’t able to get it working. If you have more luck with this, please let us know.
Guides, documentation and FAQ.
Applying for projects and login accounts.