---
description: Manage users on a Slinky cluster with slinky-user-add, seamless SSH login, and identity that survives cluster re-provisioning (replay and reconcile).
revision_date: 08.07.2026
---

# User management

On a Slinky cluster you do **not** drive [Kanidm](https://docs.verda.com/clusters/instant-clusters/local-users/) by hand. A single tool, `slinky-user-add`, provisions everything a user needs in one step:

* a **Kanidm** person (the identity + their SSH public key),
* a **POSIX** account (UID/GID) and `cluster_users` group membership,
* the per-user **subuid/subgid** mapping that [containers](https://docs.verda.com/clusters/instant-clusters/slinky/containers/) need,
* a **Slurm** account association (`default_acct` by default) so the user can submit jobs.

Run it as an admin (root) on the login/bastion node.

## Add a user

```bash
sudo slinky-user-add alice \
  --display-name "Alice Example" \
  --ssh-key "ssh-ed25519 AAAA... alice@laptop"
```

Useful options:

| Option | Purpose |
|--------|---------|
| `--ssh-key "ssh-... "` | Public key (repeatable for multiple keys). |
| `--ssh-key-file FILE` | Read one or more public keys from a file. |
| `--from-authorized-keys` | Pick keys interactively from the node's `authorized_keys`. |
| `--interactive` / `-i` | Prompt for missing values. |
| `--uid UID` | Fix the POSIX UID/GID (otherwise auto-allocated). |
| `--account ACCOUNT` | Slurm account to join (default `default_acct`). |
| `--enable-seamless` | Turn on seamless SSH (see below). |
| `--path DIR` | Filesystem holding the identity ledger (see below). |
| `--test` | Run an in-cluster NSS/Slurm smoke test after provisioning. |

`--test` is worth using the first time: it confirms the new user resolves on the workers and can launch a Slurm step (it prints the step's `uid`/`user`).

## Remove a user

```bash
sudo slinky-user-remove alice --yes
```

* `--archive-home` moves `/home/alice` under `/home/.verda/removed-users/` instead of leaving it in place.
* `--keep-kanidm` keeps the Kanidm person but drops `cluster_users` membership (revokes cluster access without deleting the identity).

## How users log in

The path for provisioned users is **seamless SSH**: it drops the user straight into the Slurm login pod over port `2222`, where they are themselves (their own UID) and the full Slurm CLI is available:

```bash
sudo slinky-user-add alice --enable-seamless --ssh-key "ssh-ed25519 AAAA..."
```

This flips `SEAMLESS_SSH_ENABLED=1` in `/etc/default/verda_seamless_ssh` and restarts `slinky-login-dnat.service`, after which the user connects with:

```bash
ssh alice@<cluster-ip> -p 2222
```

!!! info
    Seamless SSH is **off by default**: only port 22 is open until an admin enables it.

Once enabled, the `:22` admin bastion shell (`ubuntu@<cluster-ip>`) keeps working as before, while members of the kanidm `cluster_users` group are restricted to the seamless port — they can no longer open a plain bastion shell on `:22`. `SEAMLESS_SSH_PORT` (default `2222`) selects which port is the redirect; set it to `22` to flip the roles, so seamless uses the cleaner `:22` and the admin bastion shell moves to `:2222`. Only `22` or `2222` are valid.

!!! tip
    The first SSH attempt as a freshly created user can fail with `Permission denied` while the nodes' kanidm caches warm up. Retry after a few seconds.

Without seamless SSH a provisioned user can still SSH to the login node on port 22, but the wrapped Slurm CLI there is effectively admin-only: the wrappers exec into the login pod with kubectl credentials, which only the `ubuntu` admin and root have by default, and they run as the login pod's **root** user rather than as the invoking account. Enable seamless SSH for anyone who should submit their own jobs; `srun id` confirms which identity a shell submits as.

## Access control

When users submit as themselves (seamless SSH), each user is a distinct POSIX/Slurm identity and normal Slurm and filesystem boundaries apply: a user cannot `scancel` another user's job, and `/home/<user>` is private. Jobs submitted through the admin wrappers all run as root and bypass these per-user boundaries. Per-user limits and QoS are set with `sacctmgr`, see the [workshop use case](https://docs.verda.com/clusters/instant-clusters/local-users/use-case-workshop/) for a worked multi-user example.

## Identity across cluster re-provisioning (replay and reconcile)

File ownership on a shared filesystem is stored as numeric UIDs. If you delete a cluster and create a new one with the same filesystem attached, the new cluster starts with an empty identity store, and naively re-created users would get different UIDs and lose access to their own files.

Slinky clusters solve this with an **identity ledger**: a small record of every user (username, UID, display name, SSH keys) kept on the filesystem itself.

* `slinky-user-add` and `slinky-user-remove` maintain the ledger automatically. By default it lives at `/home/.verda/slinky-users/`; pass `--path <mount>` to keep it on a filesystem you retain between clusters instead.
* **`slinky-users-replay`** re-creates every user in the ledger, pinned to the original UID/GID and with the stored SSH keys. It runs automatically at boot and is idempotent, so it is safe to run by hand, for example after attaching a kept filesystem at `/main`:

    ```bash
    sudo slinky-users-replay --path /main
    ```

* If the attached filesystem holds user data but no ledger yet (a volume from before this feature), replay first **auto-seeds** the ledger from directory ownership. It only considers regular user UIDs and refuses to guess if two directories share a UID.
* **`slinky-users-reconcile`** audits the ledger against actual directory ownership and reports mismatches without changing anything; `--write-ledger` writes the inferred entries:

    ```bash
    sudo slinky-users-reconcile --path /main
    ```

!!! warning
    `/home` is created fresh with every new cluster, so a ledger kept there does not survive re-provisioning. To carry identities across clusters, keep them on the shared filesystem you retain and pass its mount point with `--path`.

!!! info
    `slinky-user-add` is the Slinky front-end to Kanidm. For the identity model itself, group management, and the manual Kanidm workflow used on **native** Slurm, see [Local users](https://docs.verda.com/clusters/instant-clusters/local-users/).