Login User Management

Login User Management gives every member of your team their own SSH identity on a Slurm Cluster — their own login name, their own keys, their own private home directory on shared storage — all from the TIR console, with no LDAP or CLI work.

Why you want thisEnable itMembersGroups & accessHome directoriesHow a member logs inDisable it

---

Why You Want This

Without it	With it
Everyone connects as root with a shared key	Everyone connects as themselves with their own key
The User column in the Jobs tab always says root	You can see whose job is whose
scancel -u root cancels the whole cluster's jobs	Each person's commands touch only their own jobs
One shared, non-persistent home directory	A private home directory per person, on shared storage, mode 0700
Removing one person means rotating a key for everyone	Revoke one person; nobody else is affected
No passwords, but also no accountability	No passwords, and full accountability

---

Enable It

Before you start

Requirement	Why
The cluster is Running	The Enable button is disabled otherwise, and the tab reads "Login User Management is not available when the cluster is not running."
A Shared File System (SFS) volume is already mounted on the cluster	Home directories are provisioned on it. The picker only offers storage already mounted — it does not mount anything for you
Update permission on Training Clusters	Otherwise the control is not shown

It must be an SFS volume, not PFS

The storage picker lists Shared File System (SFS) volumes only. Because the create form requires a Parallel File System volume, a cluster created by following the quickstart typically has PFS mounted and no SFS — and the Enable dialog then reads "No mounted storage available on this cluster." with nothing to select.

Mount an SFS volume first from the Volumes tab, then come back. Note that mounting restarts the cluster nodes and ends running jobs, so do both in one maintenance window.

Mount storage first from the Volumes tab if you have not.

Steps

1. Open the cluster → Login User Management tab.

2. The empty state reads Set up Login User Management —

   Create a persistent login server for SSH access. Manage users with groups and control cluster access per group. Home directories are provisioned automatically on the attached storage.

3. Click Enable Login User Management.

4. Read the warning in the dialog:

   Restart Required: Enabling Login User Management will restart the login service and controller.

   Please Note: Login User Management may take a few moments to become available after it is enabled.

5. Under Attach storage — "Select a storage to attach. Home directories will be provisioned at the access path shown below." — pick a volume. Each card shows its type, name and size. If nothing is mounted you see "No mounted storage available on this cluster."

6. Confirm the Home directory access path preview, which reads <mount-path>/slinky-slurm-<cluster-id>/home.

   If the list is empty, you have no SFS volume mounted — see the prerequisite above.

7. Click Enable.

Enabling restarts the login service and the controller

Open SSH sessions are dropped and anything running in a foreground shell dies. Slurm jobs already running are not cancelled, but do this during a quiet window rather than mid-deadline.

Choose the storage carefully — it becomes pinned

While Login User Management is on, that volume cannot be unmounted. Attempting it is refused with "Cannot unmount this storage as it is used for persistent login. Disable persistent login on the cluster first."

Pick a volume you intend to keep for the cluster's life, with room for everyone's home directories.

The panel shows an in-progress state for a short while, then the Groups and Members tabs appear.

---

Members

The Members tab — "Manage members for login user management".

Column	What it shows
Login Name	The Unix username they SSH as
Created By	Who added them
UID / GID	Their POSIX IDs, assigned automatically
SSH Keys	How many keys are attached
Actions	⋮ → Update SSH Keys, Delete

A group filter (All groups, or one group) narrows the list. Empty: No users available.

Add a member

1. Create Member.
2. Login Name — helper: "Lowercase [a-z0-9_-], starts with a letter."
3. SSH Public Keys (optional) — select the person's existing keys, or use Click here to add a new one inline.
4. Group — assign them to a group now, or create one inline with Click here → New group → Group Name → Add group.
5. Create Member.

Login name rules

Rule	Detail
Characters	Lowercase letters, digits and hyphens
Must start with	A lowercase letter
Length	32 characters or fewer
Errors	Login name is required · Invalid name format · Name is too long, max 50 characters allowed.

Keep names to 32 characters

The form accepts up to 50 but the API rejects anything over 32, so a long name fails only on submit. Stay well inside 32 — real usernames rarely need more.

Login names can never be reused

Even after you delete a member, that name is permanently taken in the project: "Login name '<name>' has already been used in this project and cannot be reused, even if the original identity was deleted."

Agree a convention up front — first.last or a corporate username — rather than experimenting with throwaway names.

UIDs are a limited pool

UIDs are assigned automatically from a fixed range, which caps the number of active members per project and region at 51. When it is full:

No available UID in range 1000–1050 for this project. Delete an existing identity to free a slot.

Deleting a member frees their UID. Plan for it if you have a large organisation — and note that deleting a member also deletes their home directory.

Add a member without keys, add keys later

A member with no SSH key exists but cannot log in. That is a legitimate two-step: create the account, then attach the key when the person sends their public key. Use Actions → Update SSH Keys.

Update a member's SSH keys

⋮ → Update SSH Keys opens Update SSH Keys — <login name>, warning that "The changes may take some time to be reflected".

• Attached keys — each with a remove button; removal is staged and reversible until you save
• Add keys — select more of the project's keys

Then Update. Multiple keys per member are supported — useful for a laptop and a CI runner.

Delete a member

⋮ → Delete opens Delete Member:

Are you sure you want to delete <login name>? This action cannot be undone.

Tick "I understand and want to delete <login name>." and confirm.

Deleting a member deletes their home directory

This is the only operation that removes a home directory, and its contents go with it. If there is anything worth keeping, copy it elsewhere on shared storage first.

To remove someone's access without destroying their data, revoke their group's cluster access or remove them from the group instead.

---

Groups and Cluster Access

Access is granted per group, not per member. A member reaches a cluster because one of their groups has been allowed on it.

The Groups tab — "Manage groups for login user management".

Column	What it shows
Group Name	The group name
GID Number	Its POSIX GID, assigned automatically
Members	A count; click it to jump to Members filtered to this group
Cluster Access	Allowed with a green dot, or an Allow access link
Created By	Who created it
Actions	⋮ → Allow Access / Revoke Access, Manage Members, Delete

Create a group

1. Create Group.
2. Group Name — same character rules as a login name; placeholder e.g. ml-engineers.
3. Members — select existing members, or create one inline via Click here → New member.
4. Tick "Allow this group to access the cluster." to grant access immediately.
5. Create Group.

The group name cannot be changed later

Editing a group opens Manage Members, where only membership is editable. To rename, create a new group, move the members, and delete the old one.

Allow or revoke cluster access

Action	Dialog	Effect
Allow Access	"This action will grant the <group> group access to this cluster. All members of this group will be able to access it."	Every current and future member of the group can SSH in
Revoke Access	"This action will remove the <group>'s group's access to the cluster. Members of this group will no longer be able to access it."	They lose SSH access. Home directories are kept

Both need the acknowledgement checkbox.

Membership changes take effect immediately: add someone to a group that already has access and they can log in; remove them and they cannot — unless another of their groups still grants access.

Model groups on how your team actually works

One group per team (ml-engineers, data-eng), or one per project. Then cluster access is a single click per team, and onboarding is adding one person to one group. Avoid one group per person — you lose the benefit.

Delete a group

⋮ → Delete → "Are you sure you want to delete <group>?. This action cannot be undone."

Deleting a group revokes its cluster access first. It does not delete its members — they simply lose access granted through it.

What groups do and do not control

Groups control	Groups do not control
Who can SSH to the cluster	Which Slurm partition someone may use
POSIX group membership on the login node, so shared-directory permissions work	Slurm accounting accounts or fair-share shares

Restricting a partition to a group takes one extra step

Group membership does not automatically become a Slurm AllowGroups rule. To reserve a partition for one team, add AllowGroups=<group name> to the partition's Extra partition options. The group must already exist here for the rule to match.

---

Home Directories

Fact	Detail
Path	<mount-path>/slinky-slurm-<cluster-id>/home/<login-name>
Created	Automatically, on the member's first login
Permissions	Mode 0700 — the owner and root only. No other member can read it
Shell	/bin/bash
Survives restarts?	Yes — it lives on the shared volume, not in a pod
Removed when	Only when the member is deleted
Not removed when	Disabling Login User Management, revoking group access, deleting a group, or terminating the cluster

Persistent homes make the cluster much nicer to use

Without this feature, /root is wiped on every pod restart. With it, a member's dotfiles, virtualenvs, notebooks and scripts survive restarts, image updates and reconfigures — because their home is on the shared filesystem, and every worker node sees the same path.

Home directories consume your volume's quota

Everyone's environments and scratch files land on the volume you nominated. Watch its usage — a full filesystem breaks checkpoint writes across the whole cluster, not just one person's home.

---

How a Member Logs In

ssh janedoe@<cluster-ip>

Same IP as root; different username.

Aspect	Detail
Authentication	SSH key only. There are no passwords to issue, leak or reset
Who is allowed in	Only members of a group that has been granted access to this cluster
Home directory	Their own, created on first login
Privileges	An ordinary Unix user. No sudo, no root
Slurm commands	sinfo, squeue, sbatch, srun, scontrol, sacct — all running as their own user
Their jobs	Attributed to them, so the User column in the Jobs tab is meaningful

They cannot install system packages

No sudo means no apt install. That is the right model on a shared cluster — the answer is a container image with the dependencies baked in, or a virtualenv in their home directory. It is also worth telling new members up front, because it is the first thing they hit.

Onboarding checklist

1. Ask the person for their SSH public key.
2. Add the key under the project's SSH keys.
3. Members → Create Member → login name + key + group.
4. Confirm the group has Allowed cluster access.
5. Send them: the cluster IP, their login name, and links to Submit your first job and Run containers in jobs.

Offboarding checklist

Goal	Do this
Temporarily remove access	Remove them from the group, or revoke the group's cluster access
Permanently remove them, keep their data	Remove them from every group. Do not delete the member
Permanently remove them and their data	Copy anything worth keeping out of their home directory, then Delete the member

---

Disable It

The Disable button in the header opens Disable from Cluster:

Are you sure you want to disable Login User Management from this cluster?

Tick "I understand and want to disable from this cluster." and confirm.

What happens	Detail
Member SSH access	Stops. Only the cluster's root keys work
Home directories	Preserved on the volume, untouched
Members and groups	Preserved at the project level
The nominated volume	Released, so it can be unmounted again
The cluster	Reconfigured, so the login service and controller restart

Re-enabling restores everything

Enable again on the same cluster with the same storage, re-grant the same groups, and every member finds their existing home directory at the same path. Nothing is lost by disabling.

Terminating or deleting the cluster disables it automatically — and does not delete home directories either.

---

Related Resources

• Connect to the cluster
• Storage and volumes
• Manage partitions
• Jobs tab
• Cannot connect