Gérer les utilisateurs

Cette page concerne le compte POSIX déclaré dans etc/config.yaml : déclaration, rattachement aux hôtes, mot de passe, accès SSH, désactivation.

Créer un compte Linux (POSIX)

Les utilisateurs sont déclarés une fois dans etc/config.yaml, puis rattachés aux hôtes où ils doivent ouvrir une session. Le même compte peut exister sur plusieurs machines.

Création de bout en bout

Coffre-fort, identité Kanidm, alternatives : voir Créer un compte utilisateur.

Déclarer un utilisateur

etc/config.yaml

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

Champ	Rôle
(clé)	Login du compte (ex. alice)
uid	Identifiant numérique stable
name	Nom affiché
email	Adresse (sert aussi à l’identité SSO)
profile	Profil utilisateur (environnement)
groups	Groupes (accès réseau et services)

Le déploiement du HCS lui crée aussi un compte Kanidm, sans identifiant.

Rattacher à un hôte

Sous un hôte, users liste les logins existants autorisés à s’y connecter :

etc/config.yaml

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

Via un groupe

Autre possibilité : rattacher un utilisateur à un hôte grâce à un groupe commun déclaré dans la liste groups commune.

Déployer les modifications

Toute modification de etc/config.yaml suit le même cycle :

1. Décrire le changement

   Créer ou modifier l’utilisateur et ses postes dans etc/config.yaml.

2. Régénérer et nettoyer le code

   just clean       # generate + fix + format

3. Valider dans git

   just commit "user(new): alice"

4. Déployer

   just apply @user-alice,hcs     # postes d'alice + compte Kanidm

Toujours committer avant de déployer

just clean réécrit var/generated/. Sans clean + commit, le déploiement part d’un état incohérent ou non versionné.

Définir le mot de passe

1. Définir l’empreinte

   just passwd alice

   L’utilisateur peut saisir lui-même son mot de passe. À distance, il envoie son empreinte (mkpasswd -m sha-512), à coller avec just sops sous user.alice.password-hash.

2. Valider dans git

   just commit "chore(user): alice password"

3. Déployer

   just apply @user-alice,hcs

Seul just passwd fait foi

• Pas de session avant just passwd <login>.
• Changé sur un hôte, le mot de passe est écrasé au déploiement suivant.
• just passwd-default n’enregistre que le mot de passe de référence du parc (Secrets).

Accès SSH

L’accès SSH est par clé uniquement et entièrement déclaratif, sur toute la flotte :

• Mot de passe et clavier interactif sont désactivés.
• Déclarer les clés publiques dans usr/users/<login>/authorized_keys.
• Le fichier vaut pour tous les hôtes du compte.
• Un compte sans clé déclarée peut ouvrir une session locale, hors SSH.

# usr/users/<login>/authorized_keys : une clé par ligne, `#` en commentaire
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA… alice@portable

La forge fait exception

Le compte forgejo sert le git push de tous les dépôts : ses clés sont celles que chaque utilisateur dépose dans l’interface web de la forge, pas celles de la configuration NixOS. sshd les lui demande par AuthorizedKeysCommand et non par un fichier. Une clé s’ajoute donc dans Forgejo (Paramètres → Clés SSH / GPG).

Clés privées

Une clé privée ne va jamais dans le dépôt ni dans sops : la clé d’infra, présente sur chaque hôte, la rendrait lisible par tout root du parc. Elle vit dans le coffre-fort Vaultwarden de l’utilisateur, chiffré de bout en bout.

Sur les postes choisis, rbw sert d’agent SSH et lit les clés du coffre :

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

• L’utilisateur range sa clé dans le coffre (Utiliser ma clé SSH).
• Sa clé publique rejoint ensuite authorized_keys.
• Verrouillage après 12 h sans usage : programs.rbw.settings.lock_timeout (secondes).

Pas sur un hôte atteint par ssh -A

L’agent rbw local y masquerait l’agent transféré depuis le poste.

Interdire SSH à un groupe

Les groups de config.yaml sont logiques : ils ne deviennent pas des groupes Unix, DenyGroups ne verrait donc rien. DNF les traduit en DenyUsers, hôte par hôte :

# Défaut : les comptes invités gardent leur session locale, pas SSH.
darkone.user.build.sshDeniedGroups = [ "guests" ];

Désactiver un compte

• Sur un hôte : retirer le login de la liste users de l’hôte.
• Partout : retirer l’entrée sous users:.
• Accès services : retirer l’utilisateur des groups coupe l’accès SSO.

Dans tous les cas, appliquer ensuite le cycle just clean → just commit → just apply sur les hôtes concernés.

FAQ

Une clé SSH sur YubiKey ?

La clé privée naît dans la YubiKey (FIDO2) et n’en sort jamais : rien à ranger dans le coffre. Chaque connexion demande de toucher la clé.

ssh-keygen -t ed25519-sk -O resident -O verify-required   # création, une fois

# Sur un autre poste : récupérer le handle sous le nom lu par défaut
cd ~/.ssh && ssh-keygen -K && mv id_ed25519_sk_rk id_ed25519_sk

• La clé publique (sk-ssh-ed25519@openssh.com …) rejoint authorized_keys.
• rbw ne gère pas ces clés : ssh les lit dans ~/.ssh.

À valider

Procédure non testée sur le parc.

Le trousseau GNOME après just passwd ?

Le trousseau de connexion reste chiffré par l’ancien mot de passe de session. À la session suivante ouverte au mot de passe, DNF le supprime et GNOME le recrée vide : aucune invite, l’ancien mot de passe n’ouvre plus rien.

• Applications : identifiants à ressaisir une fois (Nextcloud, comptes en ligne, Chromium).
• Ouverture par YubiKey, ou trousseau encore actif : suppression reportée à une prochaine session.
• Trousseau sans mot de passe (remède YubiKey, accessibilité) : conservé.

Pour garder un trousseau protégé par un mot de passe propre :

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

Un fichier .bkp dans un home ?

Une application a remplacé un fichier géré par Home Manager (mimeapps.list, réglages…). À l’activation suivante, il passe en <fichier>.bkp et la version déclarée reprend sa place.

• Une seule sauvegarde par fichier : la précédente est écrasée.
• Changement à conserver : le déclarer dans usr/users/<login>/default.nix.

La liste des comptes à la connexion ?

Par défaut, l’écran de connexion GDM demande de saisir l’identifiant. Pour choisir son compte dans une liste, sur un poste partagé par exemple :

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