--- title: "Manage login users" description: "Turn on Login User Management for a TIR Slurm Cluster and give each team member their own login name, SSH keys, and home directory." content_type: "how-to" product: "tir-slurm-cluster" platform: "TIR" url: "/tir/tir-slurm-cluster/how-to/manage-login-users/" topic: ["create-and-connect"] --- # Manage login users Turn on **Login User Management** for your cluster, so every team member connects with their own login name and SSH keys and works in a private home directory on shared storage. This replaces everyone sharing the cluster's `root` key. With it, the **User** column on the **Jobs** tab shows whose job is whose, and one person's `scancel` touches only their own jobs. ## Before you begin - A cluster in the **Running** state. The button to turn the feature on is available only then. - A **Shared File System** or a **Parallel File System** volume already mounted on the cluster. Home directories are created on it. The picker lists the volumes that are already mounted, so mount one first if you need to. A Parallel File System is listed only for an account with that access. To mount one, see [Mount and unmount volumes](/tir/tir-slurm-cluster/how-to/mount-and-unmount-volumes/). - Update permission on Training Clusters, which you need to see the controls on the **Login User Management** tab. ## Turn on Login User Management Choose the volume for home directories carefully, because it stays mounted while Login User Management is on. Pick one you intend to keep for the life of the cluster, with room for everyone's home directories. 1. Open the cluster and select the **Login User Management** tab. 2. Select **Enable Login User Management**. 3. Choose a quiet time: enabling restarts the cluster's login service and controller. It drops open SSH sessions and ends anything running in a foreground shell. Slurm jobs that are already running keep running. 4. Under **Attach storage**, choose a PFS or SFS volume mounted on the cluster. If there is none, mount one first. 5. Check where home directories will go: `/slinky-slurm-/home`. `` is the mount path of the volume you chose, and TIR fills in `` for you. 6. Select **Enable**. Setup takes a short while. When it finishes, you can manage **Groups** and **Members**. ## Add a member A member is one person's login. Open the **Members** tab, which lists **Login Name**, **Created By**, **UID**, **GID**, how many SSH keys are attached, and an actions menu to update keys or delete the member. A filter above the list narrows it to one group. 1. Select **Create Member**. 2. Type a **Login Name**. It must start with a lowercase letter, and after that it can use lowercase letters, digits, underscores, and hyphens, up to 32 characters. Each login name is used once per project and stays taken even after the member is deleted, so agree on a convention such as `first.last` before you start. 3. (Optional) Choose the person's SSH keys, or add a new one from the link in the dialog. A key is optional when you create the member. A member without a key cannot log in until you add one with **Update SSH Keys**, which suits someone who sends their public key later. 4. Choose a **Group**, or create one from the link in the dialog. 5. Select **Create Member**. The member appears on the **Members** tab with a UID and GID assigned for them. A member signs in with an SSH key only, so the key is the one credential to manage. A member has ordinary Unix privileges; `sudo` and root stay with the cluster's `root` login. For extra software, they use a container image with the dependencies in it, or a virtual environment in their home directory; tell new members this up front. For how many members a project can hold, see the [TIR Slurm Cluster FAQ](/tir/tir-slurm-cluster/faq/#how-many-login-users-can-a-project-have). ### Update a member's SSH keys In the **Members** tab, open the actions menu on the member's row and select **Update SSH Keys**. Remove keys or add more of the project's keys, then select **Update**. You can undo a removal until you select **Update**, and a key change can be a little slow to take effect. Each member can have several keys, for example one for a laptop and one for a CI runner. ### Delete a member In the **Members** tab, open the actions menu on the member's row and select **Delete**. Tick the acknowledgement and confirm. Deleting a member frees their UID for a different, new identity, and permanently deletes their home directory and everything in it. It is the only action that removes a home directory. Copy anything worth keeping elsewhere on shared storage first. To remove someone's access and keep their data, remove them from their groups or revoke their groups' cluster access instead. ## Organise members into groups You grant access to a cluster per group: a member reaches a cluster through a group that is allowed on it. Groups also decide POSIX group membership on the login node, so shared-directory permissions work. Slurm partitions and Slurm accounting are set separately. Model groups on how your team works: one group per team or per project. Granting cluster access is then a single action per team, and onboarding is adding one person to one group. Avoid one group per person. On the **Groups** tab: 1. Select **Create Group**. 2. Type a **Group Name**. It follows the same rules as a login name, at most 32 characters. 3. Choose the members to include. You can also add them later. 4. To grant the group access to this cluster now, tick the box that allows the group to access the cluster. 5. Select **Create Group**. To change access later, open the actions menu on the group's row and select **Allow Access** or **Revoke Access**, then tick the acknowledgement and confirm. Members of an allowed group can log in. Revoking removes their access and keeps their home directories. Adding someone to a group that already has access lets them log in at once, and removing them stops their access, unless another of their groups still grants it. **Manage Members** changes who is in a group, and **Delete** removes the group. Deleting a group asks for the same acknowledgement. It revokes the group's cluster access and keeps its members, who lose only the access that group granted. A group's name is permanent. To rename one, create a new group, move the members, and delete the old one. To reserve a Slurm partition for one team, add this line to that partition's extra options, with the name of a group that already exists here in place of ``: ```text AllowGroups= ``` Only this line reserves a partition for the group. See [Manage partitions](/tir/tir-slurm-cluster/how-to/manage-partitions/). ## What a member's home directory holds A home directory is created automatically on the member's first login, at `/slinky-slurm-/home/`. It is mode `0700`, owned by the member and `root` only, so it stays private to the member. The shell is `/bin/bash`. Because it lives on the shared volume, a home directory is kept after restarts and is visible at the same path on every node. A member's dotfiles, virtual environments, and scripts survive restarts, image updates, and reconfigures. When Login User Management is off, the login node's own disk, including `/root`, is erased whenever the login node is recreated. A home directory is removed only when its member is deleted. Turning Login User Management off, revoking a group's access, deleting a group, and terminating the cluster all keep it. Home directories count against the volume's size, and a full volume stops checkpoint writes across the whole cluster, so watch its usage. ## How a member logs in A member connects to the same address as `root`, with their own login name: ```bash ssh @ ``` Replace `` with the member's login name and `` with the cluster's public IP address. They can use `sinfo`, `squeue`, `sbatch`, `srun`, `scontrol`, and `sacct`, all running as their own user. Their jobs are attributed to them. If a member cannot log in, check that their record has an SSH key, that one of their groups has access to this cluster, and that Login User Management is turned on. See [Troubleshooting connecting to TIR Slurm Cluster](/tir/tir-slurm-cluster/troubleshooting/connecting/). ### Onboard a member 1. Ask the person for their SSH public key. 2. Add the key to TIR. See [Add an SSH key](/tir/ssh-keys/how-to/add-an-ssh-key/). 3. On **Members**, select **Create Member** and enter a login name, the key, and a group. 4. Check that the group has cluster access. 5. Send them the cluster IP, their login name, and a link to [Get started with TIR Slurm Cluster](/tir/tir-slurm-cluster/get-started/). ### Offboard a member | Goal | What to do | | ---------------------------------------- | -------------------------------------------------------------------------------- | | Remove access for a while | Remove them from the group, or revoke the group's cluster access. | | Remove them for good and keep their data | Remove them from every group, and keep the member. | | Remove them and their data | Copy anything worth keeping out of their home directory, then delete the member. | ## Turn Login User Management off This step reconfigures the cluster. To turn the feature off, select **Disable** in the tab's header, tick the acknowledgement, and confirm. Member SSH access stops, and only the cluster's `root` keys work. Home directories stay on the volume untouched, and members and groups stay in the project. The volume is released, so it can be unmounted again. The login service and controller restart. To bring it all back, turn the feature on again with the same storage and grant the same groups access. Every member then finds their existing home directory at the same path. Terminating or deleting the cluster turns Login User Management off for you, and keeps members' home directories. With members in place, the **User** column on the **Jobs** tab shows who owns each job; see [See jobs and logs](/tir/tir-slurm-cluster/how-to/see-jobs-and-logs/). If a member cannot log in, see [Troubleshooting connecting to TIR Slurm Cluster](/tir/tir-slurm-cluster/troubleshooting/connecting/#a-named-login-user-cannot-log-in).