---
title: Connect to the Cluster
sidebar_label: Overview
---

import { Terminal, Key, Users, Wifi } from 'react-feather';

# 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.

<QuickNav items={[
{ href: '#connect-as-root', label: 'Connect as root', icon: <Terminal size={13} /> },
{ href: '#find-the-address', label: 'Find the address', icon: <Wifi size={13} /> },
{ href: '#manage-the-root-keys', label: 'Manage the root keys', icon: <Key size={13} /> },
{ href: '#give-your-team-individual-logins', label: 'Individual logins', icon: <Users size={13} /> },
{ href: '#what-you-can-do-once-connected', label: 'Once connected', icon: <Terminal size={13} /> },
]} />

---

## Connect as `root`

Every cluster starts with `root` access using the SSH keys you selected at creation.

```bash
ssh root@<cluster-ip>
```

If your key is not the default identity:

```bash
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>` |

:::info The login node is the submit host, not a compute node
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 |

:::tip Convert to a reserved IP before you script anything
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](/docs/tir/SlurmCluster/manage/network-security#public-ip).
:::

### Make it convenient

```bash
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`.

:::warning Do not run long jobs in a foreground shell
An SSH session that drops takes any foreground process with it, and a
[login-service restart](/docs/tir/SlurmCluster/manage/actions#restart-actions) 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**](/docs/tir/SlurmCluster/manage/actions#update-ssh-keys)
at any time, on any cluster status.

:::danger It replaces the whole set
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](/docs/tir/SlurmCluster/manage/jobs) |
| `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**](/docs/tir/SlurmCluster/connect/login-user-management) solves this from the
console: add a member with their own SSH key, and they connect as themselves.

```bash
ssh janedoe@<cluster-ip>
```

---

## What You Can Do Once Connected

```bash
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`.

:::danger `/root` is not persistent
The 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](/docs/tir/SlurmCluster/troubleshoot/connectivity).

---

## Related Resources

- [Login User Management](/docs/tir/SlurmCluster/connect/login-user-management)
- [Submit your first job](/docs/tir/SlurmCluster/getting-started/first-job)
- [Network and security](/docs/tir/SlurmCluster/manage/network-security)
- [Cluster actions](/docs/tir/SlurmCluster/manage/actions)