Manage users

This page covers the POSIX account declared in etc/config.yaml : declaration, attachment to hosts, password, SSH access, deactivation.

Create a Linux (POSIX) account

Users are declared once in etc/config.yaml, then attached to the hosts where they must log in. The same account can exist on several machines.

End-to-end creation

Vault, Kanidm identity, alternatives : see Create a user account.

Declare a user

etc/config.yaml

users:
  alice:
    uid: 1000
    name: "Alice Martin"
    email: "alice@domain.tld"
    profile: "advanced"
    groups: ["global", "idm-devs"]

Field	Role
(key)	Account login (e.g. alice)
uid	Stable numeric identifier
name	Display name
email	Address (also used for SSO identity)
profile	User profile (environment)
groups	Groups (network access and services)

The HCS deployment also creates a Kanidm account for them, without credentials.

Attach to a host

Under a host, users lists the existing logins allowed to connect to it:

etc/config.yaml

hosts:
  poste-alice:
    profile: "desktop"
    users: ["alice"]

Via a group

Another possibility: attach a user to a host through a common group declared in the shared groups list.

Deploy the changes

Any change to etc/config.yaml follows the same cycle:

1. Describe the change

   Create or modify the user and their machines in etc/config.yaml.

2. Regenerate and clean the code

   just clean       # generate + fix + format

3. Validate in git

   just commit "user(new): alice"

4. Deploy

   just apply @user-alice,hcs     # alice's machines + Kanidm account

Always commit before deploying

just clean rewrites var/generated/. Without clean + commit, the deployment starts from an inconsistent or unversioned state.

Set the password

1. Set the hash

   just passwd alice

   The user can enter their own password. Remotely, they send their hash (mkpasswd -m sha-512), to be pasted with just sops under user.alice.password-hash.

2. Validate in git

   just commit "chore(user): alice password"

3. Deploy

   just apply @user-alice,hcs

Only just passwd is authoritative

• No session before just passwd <login>.
• If changed on a host, the password is overwritten at the next deployment.
• just passwd-default only records the fleet’s reference password (Secrets).

SSH Access

SSH access is key-only and entirely declarative, across the whole fleet :

• Passwords and interactive keyboard are disabled.
• Declare public keys in usr/users/<login>/authorized_keys.
• The file applies to all hosts of the account.
• An account with no declared key can open a local session, outside SSH.

# usr/users/<login>/authorized_keys : one key per line, `#` starts a comment
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA… alice@portable

The forge is the exception

The forgejo account serves the git push of every repository: its keys are the ones each user deposits in the forge’s web interface, not the ones from the NixOS configuration. sshd asks it for them via AuthorizedKeysCommand rather than from a file. A key is therefore added in Forgejo (Settings → SSH / GPG Keys).

Private keys

A private key never goes anywhere near the repository or sops : the infra key, present on every host, would make it readable by any root account of the cluster. It lives in the user’s Vaultwarden vault, encrypted end to end.

On the selected workstations, rbw acts as the SSH agent and reads the keys from the vault :

# usr/users/<login>/default.nix (advanced, admin, nix-admin profiles…)
darkone.home.advanced.enableVaultwardenSsh = true;

• The user stores their key in the vault (Use my SSH key).
• Its public key then goes into authorized_keys.
• Locks after 12 h of inactivity : programs.rbw.settings.lock_timeout (seconds).

Not on a host reached via ssh -A

The local rbw agent would there mask the agent forwarded from the workstation.

Denying SSH to a group

The groups in config.yaml are logical: they do not become Unix groups, so DenyGroups would see nothing. DNF translates them into DenyUsers, on a per-host basis:

# Default: guest accounts keep their local session, no SSH.
darkone.user.build.sshDeniedGroups = [ "guests" ];

Disable an account

• On one host: remove the login from the host’s users list.
• Everywhere: remove the entry under users:.
• Service access: removing the user from groups cuts SSO access.

In all cases, then apply the just clean → just commit → just apply cycle on the affected hosts.

FAQ

An SSH key on a YubiKey?

The private key is born inside the YubiKey (FIDO2) and never leaves it : nothing to store in the vault. Every connection requires touching the key.

ssh-keygen -t ed25519-sk -O resident -O verify-required   # creation, once

# On another workstation: retrieve the handle under the default name
cd ~/.ssh && ssh-keygen -K && mv id_ed25519_sk_rk id_ed25519_sk

• The public key (sk-ssh-ed25519@openssh.com …) joins authorized_keys.
• rbw does not manage these keys : ssh reads them from ~/.ssh.

To be validated

Procedure not tested on the estate.

The GNOME keyring after just passwd?

The login keyring remains encrypted by the old session password. At the next session opened with the password, DNF removes it and GNOME recreates it empty: no prompt, the old password no longer opens anything.

• Applications: credentials to re-enter once (Nextcloud, online accounts, Chromium).
• Login with YubiKey, or keyring still active: removal deferred to a later session.
• Keyring without a password (YubiKey fix, accessibility): kept.

To keep a keyring protected by a clean password:

# usr/users/<login>/default.nix
darkone.home.gnome.keepKeyring = true;

A .bkp file in a home directory?

An application has replaced a file managed by Home Manager (mimeapps.list, settings…). At the next activation, it becomes <file>.bkp and the declared version takes its place back.

• Only one backup per file: the previous one is overwritten.
• Change to keep: declare it in usr/users/<login>/default.nix.

The account list at login?

By default, the GDM login screen asks you to type your username. To pick your account from a list, on a shared machine for example :

# usr/machines/<hôte>/configuration.nix
darkone.graphic.gnome.enableGdmSelector = true;