Connecting to the clusters#
SCITAS offers two categories of clusters, each tailored to specific usage scenarios:
- Academic Purpose Clusters (Helvetios and Izar): exclusively accessible with student or course accounts and are intended for academic purposes only (e.g., Master projects, coursework or theses).
- Research Purpose Clusters (Jed and Kuma): available only for pay-per-use accounts and are designed for broader research purposes, including industrial or external collaborations.
Account
Ensure you have the appropriate account type for the cluster you intend to use. If you need assistance determining your eligibility or setting up access, please contact the support team.
Connection to the clusters using SSH#
Before being able to connect to one of SCITAS' clusters, you will need:
- A valid EPFL GASPAR account
- An approved SCITAS account
- The client computer needs to be inside the EPFL network, or the user should establish a VPN connection
To connect to one of the clusters, you will need to use the SSH protocol. If you don't need to use GUIs:
If you wish to use GUIs, you need to add the-X
option to enable X11 forwarding
On the Izar cluster, you will be asked for a
password every time you want to ssh
a node from the frontend. To avoid this,
please forward your agent :
Here, <username>
is your GASPAR username and <cluster>
is one of the
following: kuma
, jed
, izar
, or helvetios
. Please note that Helvetios is reserved
for classes.
EPFL Network
Please note that from outside of the EPFL network, you will need to connect to the VPN.
SSH clients
SSH clients are available by default on Apple macOS and Linux.
For MS Windows, we recommend Git Bash or Windows Subsystem for Linux.
For SFTP we recommend FileZilla
Setting up a passwordless connection#
Every time you will connect to one of the machines using SSH, you will be prompted to enter your GASPAR password. You can also use a second method that will use a pair of cryptographic keys instead. This way, you will be able to connect without password from trusted clients only.
Overwriting your current SSH key
If you already had generated ssh keys, do not repeat this procedure at the cost of overwriting them. You can simply reuse the ones you have already generated.
If it is not already done, you will first need to generate a cryptographic key pair:
$ ssh-keygen -t ed25519 -C "${USER}@clusters" -f ${HOME}/.ssh/id_ed25519
Generating public/private ed25519 key pair.
Your identification has been saved in /home/user/.ssh/id_ed25519
Your public key has been saved in /home/user/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:Scb2MvoeHNItjuzsYxeOfnPApWqhBDXKHjNkLG6FHso username@clusters
The key's randomart image is:
+--[ED25519 256]--+
| .. |
|.o+.o . |
|==oo . = |
|.EB = +. |
|.. = ..Soo |
| . ...*== |
| . .+=+o |
| .o*.=.. |
| ===oo |
+----[SHA256]-----+
- A passphrase (password) to protect your key.
Once this is done, you will have a folder ~/.ssh
which contains two files:
id_ed25519.pub
: this is your public key. It is not a secret and you can share it with anyone.id_ed25519
: this is your secret key. Do not share it at any condition. It has to stay on your computer.
You can now export your public key to the clusters so that you can connect without password:
Note that since the/home
folder is shared between all the machines, you will
need to do this once on any machine.
You can now test that everything went correctly by connecting to one of the clusters. You may be asked to enter your passphrase once, but after that all the connections will be done without password.
Security risk
Please, note that with this method, everyone connected to your session will be able to connect to any machine for which you have set up a passwordless connection. Obviously, this procedure should not be done on a public computer.
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!#
An SSH server is identified by a key used to derive the connection's security. A
fingerprint of the key is kept on the SSH client at the first login and compared
at every consequent login. If the key changes after some time, the SSH client
refuses to connect and you see this error. It's required from you that you check
that the server you're connecting to is legit and you're not being hacked.
Usually, it means contacting the server administrator to ask for the new key
fingerprint. You can then remove the old offending key from your
~/.ssh/know_hosts
file and connect again. You'll be asked to accept the new
key fingerprint.
Check the current fingerprint, against the list you can find below:
If the fingerprint doesn't match, remove the offending key (in this example for
jed.hpc.epfl.ch
):
Here's the list of fingerprints for our cluster frontends:
helvetios.hpc.epfl.ch
ECDSA
MD5:41:1b:8f:e5:2d:f2:17:f9:16:4f:41:ce:29:b4:7f:f0
SHA256:j0rsCt0HglJl3a9fQkpl+rSLfKCcY9oKgA7AGqkr36o
ED25519
MD5:f1:f9:dc:f3:e6:29:b2:e0:2b:cc:42:76:0f:63:98:97
SHA256:fKaxjyBL31xRHqIU0/gmti2aYHQa3Ons0mNxMGh/mo8
RSA
MD5:f9:4e:85:2a:9e:bf:f9:9f:77:3b:ff:a6:a9:97:87:97
SHA256:z5tFjITbGyLpnK0T1bEkXHtWEyBxF/kUHGp5YT73R7c
izar.hpc.epfl.ch
ECDSA
MD5:75:bf:66:87:94:39:94:93:9a:be:b5:06:2a:89:a4:67
SHA256:CmnfF53AEyqgT0t0PfoRRxZ/3cLbanzMPZ4jcEmlItw
ED25519
MD5:2a:9e:b4:bd:d5:2c:0c:7e:22:db:a9:b3:fb:ab:13:b6
SHA256:q327bbvtHQTCLisv7au0d3rxw2JWO/+l3Gn2l0Z8AD4
RSA
MD5:63:eb:8c:b5:d8:ef:2f:df:c1:9f:ab:85:c3:30:29:2c
SHA256:JVMVBiqHiXVjcwzIpISxtxZHArjfYbBjoV6o3XUbkoA
jed.hpc.epfl.ch
ECDSA
MD5:4b:5e:1f:87:dd:49:88:f9:71:c4:9a:e8:0f:49:83:71
SHA256:QUxloUiagCgtl8yzkyOrilpFCbdREM2V0d3+SoubZfM
ED25519
MD5:c5:91:aa:ed:a0:f6:c0:9f:e1:cf:2c:20:23:5d:18:7b
SHA256:qxMAAQZRqbHbsmcO+z1MeNfTH4aYjYHgNtLAGN+fERE
RSA
MD5:ea:48:8f:33:f3:49:c0:4f:17:c7:f0:8a:d7:e6:ba:e9
SHA256:A2QhU25Zy+kkNHVN+Z5LiksOEczHVmXXCTFH8XvOxHc
kuma.hpc.epfl.ch
ECDSA
MD5:c2:0d:da:2e:5a:29:fa:4e:b3:4c:b3:c1:9f:53:fb:d6
SHA256:Y4DicuOpInMIFShZXHfSNoLX++Wx6M4jRXOX2H+8Ows
ED25519
MD5:3e:d1:e9:4e:9b:67:13:bd:09:ca:29:3a:69:82:18:16
SHA256:h24nEbxUtKIbXdtWgZLjo7YgRYmaSPOfPmLAHgnaF7E
RSA
MD5:f7:db:13:73:15:d1:a8:5d:a3:7c:a2:56:b3:e9:35:5e
SHA256:qybRVV995yOb3OlI+b5aUeuXc3AicftyTPQ0Tz4miTk
MOTD#
Upon connection on one of our clusters you will be greet by a Message Of The Day (MOTD):
The MOTD contains four main parts:
-
The header, which contains the cluster name, a link to its specification and sometimes other information. This part is different for each cluster.
-
The announcements, which contains multiple section. Each section can have multiple messages ordered by priority, high at the top. This part is different for each cluster.
-
The Sausage part, which displays your current consumption of all our clusters for the current month. This part is generic.
-
The infos part, which contains a list of links and contact to help you with SCITAS. This part is generic and displays also the name and the version of the software build by SCITAS to display this MOTD.