--- title: Login User Management sidebar_label: Login User Management --- import { Users, UserPlus, Layers, Home, Trash2, Shield } from 'react-feather'; # 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. }, { href: '#enable-it', label: 'Enable it', icon: }, { href: '#members', label: 'Members', icon: }, { href: '#groups-and-cluster-access', label: 'Groups & access', icon: }, { href: '#home-directories', label: 'Home directories', icon: }, { href: '#how-a-member-logs-in', label: 'How a member logs in', icon: }, { href: '#disable-it', label: 'Disable it', icon: , destructive: true }, ]} /> --- ## 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](/docs/tir/SlurmCluster/manage/jobs) 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 | :::danger 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](/docs/tir/SlurmCluster/manage/storage#mount-a-volume), 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](/docs/tir/SlurmCluster/manage/storage) 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 `/slinky-slurm-/home`. If the list is empty, you have no SFS volume mounted — see the prerequisite above. 7. Click **Enable**. :::danger 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. ::: :::warning 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.* | :::warning 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. ::: :::danger 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**. :::info 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 ``? This action cannot be undone. Tick **"I understand and want to delete ``."** and confirm. :::danger 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](#groups-and-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**. :::info 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 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 ``'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. :::tip 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 ``?. 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 | :::info 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=` to the partition's [**Extra partition options**](/docs/tir/SlurmCluster/slurm-configuration/partitions#extra-partition-options). The group must already exist here for the rule to match. ::: --- ## Home Directories | Fact | Detail | |------|--------| | Path | `/slinky-slurm-/home/` | | 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 | :::tip 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. ::: :::warning 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 ```bash ssh janedoe@ ``` 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 | :::info 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](/docs/tir/SlurmCluster/containers/) 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](/docs/tir/SlurmCluster/getting-started/first-job) and [Run containers in jobs](/docs/tir/SlurmCluster/containers/run-containers). ### 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 | :::info 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](/docs/tir/SlurmCluster/connect/) - [Storage and volumes](/docs/tir/SlurmCluster/manage/storage) - [Manage partitions](/docs/tir/SlurmCluster/slurm-configuration/partitions) - [Jobs tab](/docs/tir/SlurmCluster/manage/jobs) - [Cannot connect](/docs/tir/SlurmCluster/troubleshoot/connectivity)