Connect to the Cluster
You reach a Slurm Cluster by SSH to its login node. That is where you edit scripts, submit jobs
with sbatch, and import container images.
Connect as root
Every cluster starts with root access using the SSH keys you selected at creation.
ssh root@<cluster-ip>
If your key is not the default identity:
ssh -i ~/.ssh/<your-key> root@<cluster-ip>
The console gives you the exact command. Open the cluster and click Connect in the top-right area — the panel is headed Use Shell to run freeform commands and each command has a copy button:
| The panel says | Command |
|---|---|
| Connect to the head instance using SSH | ssh root@<ip> |
| To view information about nodes and partitions. | sinfo |
| To view and modify configuration and state. | scontrol show nodes |
| To submit a batch script for later execution | sbatch <PATH OF SCRIPT> |
The sstat command can be used to track the resource usage of your jobs. | sstat -j <Job ID> |
The scontrol command can be used to track your jobs. | scontrol show job <Job ID> |
It has your storage mounts and outbound network access, but no GPUs allocated to your work. Run
training through sbatch or srun, not directly in the shell.
Find the Address
The cluster's IP appears in two places:
- Details tab → Connection Details → SSH Command, with a copy button
- Network & Security tab → Network → Public IP
The IP carries a badge:
| Badge | Meaning |
|---|---|
| Floating | Assigned from a pool. It can change if the cluster's network resources are recreated |
| Reserved | Held for your account. Stable |
A floating IP is fine for a quick look, but any script, CI job, ~/.ssh/config entry or bookmark
that hard-codes it will break when it changes. Network & Security → Convert to reserved pins it.
See Network and security.
Make it convenient
cat >> ~/.ssh/config <<'EOF'
Host slurm-train
HostName <cluster-ip>
User root
IdentityFile ~/.ssh/<your-key>
ServerAliveInterval 30
EOF
Then ssh slurm-train. ServerAliveInterval keeps idle sessions from being dropped mid-squeue.
An SSH session that drops takes any foreground process with it, and a
login-service restart drops every session.
Submit with sbatch — a Slurm job survives both. If you must hold a shell, use tmux or screen,
knowing they too die with the pod.
Manage the Root Keys
Change the keys with Actions → Update SSH Keys at any time, on any cluster status.
Keys left out of the selection lose access immediately. Keep a second key on every cluster so a lost laptop is an inconvenience, not a lockout.
Give Your Team Individual Logins
A shared root key works for one person and stops working well the moment a team shares the cluster:
With shared root | With individual logins |
|---|---|
Every job is submitted by root — you cannot tell whose it is | Jobs carry the real user in the Jobs tab |
scancel -u root cancels everyone's jobs | Each person only affects their own |
| Everyone shares one home directory, and it is not persistent | Each person gets a private home directory on shared storage |
| Removing one person's access means rotating a key for everybody | Revoke one person, nobody else notices |
Login User Management solves this from the console: add a member with their own SSH key, and they connect as themselves.
ssh janedoe@<cluster-ip>
What You Can Do Once Connected
sinfo # partitions and node states
squeue # the queue
sbatch train.sh # submit a job
srun --gres=gpu:1 --pty bash # interactive shell on a compute node
sacct -u $USER -S today # your job history
scontrol show config # the live slurm.conf
enroot import -o /pfs/images/x.sqsh docker://... # cache a container image
Your PFS, SFS and dataset mounts are at the paths you chose, identical here and on every worker
node — which is why job scripts, datasets, checkpoints and container images all belong there rather
than in /root.
/root is not persistentThe login node's own filesystem is wiped whenever the pod is recreated — a login-service restart, an image update, a reconfigure. Keep your scripts on a mounted volume. This catches people out constantly.
If You Cannot Connect
| Symptom | Likely cause |
|---|---|
Permission denied (publickey) | The matching private key is not being offered, or the key is not on the cluster |
Connection refused / timeout | Port 22 not open in the security group, or the cluster is not Running |
Host key verification failed | The login node was recreated. Remove the stale entry from ~/.ssh/known_hosts |
| Worked before, not now | The floating IP changed |
A named user cannot log in, root can | Their group has no cluster access, or their key is not attached |
Full walkthrough: Cannot connect.