Verrouillage 2FA Proxmox : comment l’éviter (et récupérer rapidement)

Le modèle mental : ce que protège réellement le 2FA de Proxmox

L’authentification Proxmox VE n’est pas une chose monolithique. C’est une pile de composants qui se rejoignent au formulaire de connexion de l’interface Web. Si vous voulez prévenir les verrouillages — et récupérer proprement lorsqu’ils surviennent — vous devez savoir à quel niveau vous échouez.

Couches qui comptent

• Realms définissent où résident les utilisateurs : pam (utilisateurs Linux via PAM), pve (interne à Proxmox), plus des options externes comme LDAP/AD.
• Utilisateurs sont des identifiants qualifiés par realm comme alice@pam ou ops@pve.
• Méthodes 2FA (TOTP, WebAuthn, codes de récupération, etc.) sont liées à un utilisateur, pas à un nœud. Dans un cluster, ça a son importance.
• Le plan de gestion est principalement l’API et l’UI Proxmox (pveproxy/pvedaemon). Le perdre ne met pas les VM hors service, mais bloque votre capacité à piloter.
• Accès root (console locale/SSH) est le véritable break-glass. Si vous perdez aussi root, vous n’êtes plus en train de dépanner le 2FA — vous faites une récupération d’hôte.

Voici la vérité inconfortable : un « verrouillage 2FA » n’est souvent pas à propos du 2FA. Il s’agit de plomberie d’identité. La personne d’astreinte ne peut pas s’authentifier parce que le realm ne peut pas valider les mots de passe, l’horloge du nœud est fausse, l’UI est en panne, ou la configuration 2FA de l’utilisateur est à moitié supprimée et rejette tout.

Idée paraphrasée de Werner Vogels : « Tout échoue, tout le temps — donc concevez pour la récupération, pas pour la perfection. »

Et oui, Proxmox est assez bon pour la récupération — si vous vous êtes préparé. Si vous ne l’avez pas fait, Proxmox vous enseignera la différence entre « configuration sécurisée » et « panne auto-infligée ».

Faits et contexte intéressants (pourquoi ça déraille)

1. TOTP est basé sur le temps, pas sur la magie. Il dépend de l’horloge du serveur qui soit correcte. Quelques minutes de dérive peuvent sembler être un « 2FA cassé ».
2. Le 2FA s’est généralisé parce que les mots de passe ont échoué à l’échelle. Le grand basculement a eu lieu dans les années 2010 avec l’industrialisation du phishing et de la réutilisation de crédentiels.
3. PAM précède le 2FA moderne de plusieurs décennies. Linux PAM (Pluggable Authentication Modules) est un cadre ancien qui peut intégrer de nombreuses méthodes d’authentification, mais les erreurs de configuration sont… intemporelles.
4. Le realm pam de Proxmox signifie « comptes système », donc vos utilisateurs Linux et leurs politiques de mot de passe comptent. Désactiver SSH pour root ? D’accord. Perdre la console root ? Pas d’accord.
5. Les clusters amplifient les erreurs d’identité. Un changement qui casse l’authentification sur un nœud peut vous laisser bloqué si ce nœud est le seul accessible.
6. L’adoption U2F/WebAuthn a augmenté parce que TOTP se laisse phisher. Mais WebAuthn introduit un risque différent : perdre la clé physique sans sauvegarde.
7. Les codes de récupération sont plus anciens que la plupart ne le pensent. Les services consommateurs les utilisaient tôt parce que les équipes de support avaient besoin d’un moyen non-télépathique d’aider les utilisateurs verrouillés.
8. Les politiques « 2FA partout » oublient souvent les comptes de service. Les connexions humaines sont renforcées, l’automatisation casse, et quelqu’un désactive « temporairement » des contrôles pendant une crise.

Comment éviter le verrouillage 2FA : règles que j’applique

Règle 1 : Avoir une voie break-glass testée qui ne dépend pas du même 2FA

Ne confondez pas « avoir root » avec « avoir un plan break-glass ». Un plan est quelque chose que vous pouvez exécuter à 03:00 pendant que votre manager vous surveille.

Le schéma pratique est :

• Au moins deux identités administratives qui peuvent joindre le cluster, stockées dans un gestionnaire de mots de passe avec accès audité.
• Au moins une façon hors ligne de compléter le second facteur ou de le contourner légitimement (codes de récupération, seconde clé matérielle, ou un processus contrôlé de remise à zéro du 2FA).
• Au moins un chemin d’accès hôte hors-bande (IPMI/iDRAC/iLO, KVM-over-IP, ou console physique) qui contourne entièrement l’UI Web.

Règle 2 : Ne laissez jamais « l’administrateur unique » s’enregistrer en 2FA sans un second admin disponible

S’il n’existe qu’un seul compte avec les droits Administrator, et que vous activez le 2FA dessus, vous êtes à un faux pas d’une panne du plan de gestion. Enregistrez le 2FA comme une opération à deux personnes : une personne change, l’autre vérifie et reste connectée jusqu’à confirmation de la récupération.

Règle 3 : Traitez la synchronisation temporelle comme faisant partie de l’authentification

Dans Proxmox, la dérive du temps n’est pas « un problème de monitoring ». C’est « l’authentification peut casser ». Exécutez NTP/chrony partout, vérifiez-le après les redémarrages, et surveillez la dérive.

Règle 4 : Stockez les données de récupération 2FA comme vous stockez les clés hôtes SSH : soigneusement, hors ligne et sous contrôle

Les codes de récupération ne devraient pas vivre dans un chat partagé. Mettez-les dans un coffre-fort de gestionnaire de mots de passe avec journalisation d’accès, ou dans un magasin chiffré hors ligne dans un coffre ignifuge. Rendez cela ennuyeux. L’ennui est bon.

Règle 5 : N’éliminez pas la redondance au nom de la « netteté »

Les gens aiment « nettoyer les anciens comptes ». Super. Faites-le après avoir vérifié que les comptes restants peuvent toujours s’authentifier, peuvent toujours administrer, et ont des sauvegardes 2FA fonctionnelles. Le cimetière est plein d’annuaires d’identité bien rangés.

Petite blague #1 : L’authentification à deux facteurs est formidable jusqu’à ce que votre second facteur décide de prendre des vacances sans déposer de congés.

Playbook de diagnostic rapide

Ceci est la séquence « arrêtez de deviner ». Elle est conçue pour vous dire si le goulot d’étranglement est (a) vous, (b) le temps, (c) le realm, (d) les services Proxmox, ou (e) le réseau.

Premier : confirmez que vous échouez sur l’authentification, pas sur la connectivité

• Pouvez-vous atteindre le port UI du nœud (8006) ?
• L’erreur dans le navigateur est-elle un problème HTTP/TLS ou un rejet d’authentification ?
• Les autres utilisateurs échouent-ils aussi ?

Second : vérifiez l’heure et la santé de base de l’hôte

• Vérifiez l’état de synchronisation NTP et l’heure actuelle.
• Vérifiez que pveproxy et pvedaemon tournent.
• Vérifiez l’espace disque (oui, vraiment). Les disques pleins cassent des choses étranges.

Troisième : identifiez quel realm est impliqué et s’il est joignable

• @pam dépend de Linux PAM/mots de passe.
• @pve dépend de l’auth interne Proxmox.
• Les realms LDAP/AD dépendent du réseau + santé de l’annuaire + confiance TLS.

Quatrième : décidez si vous avez besoin d’un « login break-glass » ou d’une « réinitialisation 2FA »

• Si vous avez une session admin ouverte ailleurs, utilisez-la pour réparer.
• Sinon, utilisez la console root/SSH pour réparer les réglages d’identité et la configuration 2FA.

Cinquième : contenir le risque

• Ne désactivez pas les contrôles de sécurité globalement si vous n’avez besoin de réinitialiser qu’un seul utilisateur.
• Ne redémarrez pas les services du cluster au hasard. Redémarrez le composant minimal nécessaire, avec un plan de retour en arrière.

Tâches pratiques : commandes, sorties et décisions

Ce sont des tâches pratiques que j’exécute réellement. Chacune inclut ce que la sortie signifie et la décision à prendre. Exécutez-les sur le shell d’un nœud Proxmox en root (ou via sudo) sauf indication contraire.

Task 1: Confirm the node clock is sane (TOTP depends on it)

cr0x@server:~$ timedatectl
               Local time: Fri 2025-12-26 13:42:11 UTC
           Universal time: Fri 2025-12-26 13:42:11 UTC
                 RTC time: Fri 2025-12-26 13:42:11
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Signification : Si System clock synchronized est no, les codes TOTP peuvent ne jamais être validés.

Décision : Si non synchronisé, corrigez d’abord l’heure (chrony/ntp), puis réessayez la connexion avant de changer des réglages d’auth.

Task 2: Check chrony sync quality (drift can be subtle)

cr0x@server:~$ chronyc tracking
Reference ID    : 8A2B3C4D (ntp1.internal)
Stratum         : 3
Ref time (UTC)  : Fri Dec 26 13:41:58 2025
System time     : 0.000012345 seconds slow of NTP time
Last offset     : -0.000010221 seconds
RMS offset      : 0.000035000 seconds
Frequency       : 12.345 ppm fast
Residual freq   : -0.001 ppm
Skew            : 0.120 ppm
Root delay      : 0.003210 seconds
Root dispersion : 0.001900 seconds
Update interval : 64.0 seconds
Leap status     : Normal

Signification : Les offsets en millisecondes sont acceptables ; des secondes ne le sont pas. Le leap status doit être Normal.

Décision : Si l’offset est important ou que le leap status n’est pas Normal, corrigez le NTP et envisagez de vérifier la source d’horloge de l’hyperviseur si c’est une VM.

Task 3: Verify the Proxmox UI service is up

cr0x@server:~$ systemctl status pveproxy --no-pager
● pveproxy.service - PVE API Proxy Server
     Loaded: loaded (/lib/systemd/system/pveproxy.service; enabled)
     Active: active (running) since Fri 2025-12-26 13:12:02 UTC; 30min ago
   Main PID: 1456 (pveproxy)
      Tasks: 4 (limit: 6144)
     Memory: 120.5M
        CPU: 18.233s
     CGroup: /system.slice/pveproxy.service
             ├─1456 pveproxy
             └─1457 pveproxy worker

Signification : S’il n’est pas en cours, vous n’êtes pas verrouillé par le 2FA ; vous êtes verrouillé par une défaillance de service.

Décision : Si inactive/failed, inspectez les logs et redémarrez pveproxy ; ne touchez pas au 2FA pour l’instant.

Task 4: Check the auth daemon too (it backs the API)

cr0x@server:~$ systemctl status pvedaemon --no-pager
● pvedaemon.service - PVE API Daemon
     Loaded: loaded (/lib/systemd/system/pvedaemon.service; enabled)
     Active: active (running) since Fri 2025-12-26 13:12:00 UTC; 30min ago
   Main PID: 1410 (pvedaemon)
      Tasks: 4 (limit: 6144)
     Memory: 78.1M
        CPU: 10.104s
     CGroup: /system.slice/pvedaemon.service
             ├─1410 pvedaemon
             └─1411 pvedaemon worker

Signification : Si pvedaemon est tombé, les requêtes d’auth peuvent échouer d’une manière qui ressemble à des problèmes de connexion.

Décision : Si il échoue, corrigez le daemon et retestez avant de modifier des utilisateurs.

Task 5: Look at recent authentication errors in logs

cr0x@server:~$ journalctl -u pveproxy -u pvedaemon --since "1 hour ago" --no-pager | tail -n 40
Dec 26 13:25:10 pve1 pveproxy[1457]: authentication failure; rhost=192.0.2.44 user=ops@pve msg=TOTPs rejected
Dec 26 13:25:12 pve1 pveproxy[1457]: failed login attempt: user 'ops@pve' - authentication failure
Dec 26 13:28:01 pve1 pveproxy[1457]: authentication failure; rhost=192.0.2.44 user=alice@pam msg=PAM authentication failed
Dec 26 13:30:22 pve1 pvedaemon[1411]: worker failed: unable to get local IP address

Signification : Cela vous dit si l’échec est un rejet de TOTP, une défaillance PAM, ou une bizarrerie réseau/service sous-jacente.

Décision : Si c’est un rejet TOTP, vérifiez l’heure et la configuration 2FA de l’utilisateur. Si c’est une défaillance PAM, vérifiez le compte Linux/mot de passe et la pile PAM. Si c’est un problème réseau/hostname, corrigez le réseau/DNS de l’hôte.

Task 6: Confirm you’re not out of disk (because everything breaks when disks fill)

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/mapper/pve-root   94G   91G  1.2G  99% /

Signification : À 99% vous êtes en territoire « échecs aléatoires ». Les renouvellements de certificats, les logs et les écritures de config peuvent échouer.

Décision : Libérez de l’espace immédiatement (vider les logs, supprimer les vieux ISOs, élaguer les sauvegardes) avant de changer les réglages d’auth.

Task 7: List Proxmox users and see what realm they live in

cr0x@server:~$ pveum user list
userid        enable expire firstname lastname email
root@pam      1      0
alice@pam     1      0
ops@pve       1      0
auditor@pve   1      0

Signification : Vous pouvez immédiatement voir qui est interne (@pve) versus système/PAM (@pam).

Décision : Si votre seul admin est un utilisateur fragile d’un realm externe, créez un administrateur local break-glass dans @pve ou assurez-vous que root@pam est contrôlé et testé.

Task 8: Check which users have admin rights (don’t guess)

cr0x@server:~$ pveum acl list | head -n 20
/ - user root@pam - role Administrator
/ - user ops@pve - role Administrator
/ - user auditor@pve - role PVEAuditor

Signification : Les ACL vous indiquent qui peut réellement réparer le problème depuis l’UI/API.

Décision : S’il n’y a qu’un seul Administrator, arrêtez-vous et ajoutez un second avant d’activer ou modifier les politiques 2FA.

Task 9: Inspect 2FA configuration at the user level

cr0x@server:~$ pveum user get ops@pve
userid: ops@pve
enable: 1
expire: 0
firstname: Operations
lastname: Team
email: ops@example.invalid
groups: admins
keys: 
totp:
  - id: totp1
    enable: 1
    created: 2025-07-10 09:21:33
    comment: primary phone

Signification : Cela montre si TOTP est configuré et activé pour cet utilisateur.

Décision : Si l’utilisateur ne peut plus générer de TOTP valides, vous avez besoin d’une réinitialisation contrôlée : supprimer/désactiver le TOTP obsolète et enregistrer un nouveau facteur.

Task 10: Check configured realms (spot LDAP/AD dependence)

cr0x@server:~$ pveum realm list
realm    type   comment
pam      pam    Linux PAM standard authentication
pve      pve    Proxmox VE authentication server
corp     ldap   Corporate directory

Signification : Si vos admins s’authentifient via corp et que LDAP est en panne, vous échouerez aux connexions « mystérieusement ».

Décision : Si un realm externe est requis pour l’accès admin, assurez-vous d’avoir un admin local en secours.

Task 11: Validate Linux/PAM path for @pam users

cr0x@server:~$ getent passwd alice
alice:x:1001:1001:Alice Admin,,,:/home/alice:/bin/bash

Signification : Si getent ne trouve pas l’utilisateur, l’auth PAM échouera. Si vous dépendez de NSS/SSSD/LDAP, cela peut casser lors d’une panne d’annuaire.

Décision : Si l’utilisateur est manquant, corrigez la source d’identité (utilisateur local, SSSD, LDAP) ou utilisez un compte break-glass local.

Task 12: Check if SSH/root access is available (your break-glass reality check)

cr0x@server:~$ ssh -o PreferredAuthentications=publickey root@127.0.0.1 'pveversion'
pve-manager/8.2.2/6f3a1d15 (running kernel: 6.8.12-2-pve)

Signification : Si vous pouvez exécuter ceci localement ou via votre réseau de gestion, vous pouvez récupérer sans dépendre de l’UI Web.

Décision : Si SSH/root est indisponible, vous devez utiliser la console hors-bande (IPMI/iDRAC/iLO) ou un accès physique — planifiez en conséquence.

Task 13: Confirm cluster quorum status (avoid “fixing auth” during split-brain)

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-cluster
Config Version:   42
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Fri Dec 26 13:44:02 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.23
Quorate:          Yes

Signification : Si le quorum est perdu, certaines écritures de config et opérations de cluster se comporteront différemment. Les données d’auth peuvent être incohérentes si vous êtes dans un mauvais état de cluster.

Décision : Si non quorate, stabilisez d’abord le cluster ou faites les changements sur le nœud qui détient actuellement une config cohérente (avec une extrême prudence).

Task 14: Inspect recent failed logins from system auth logs (PAM/SSH context)

cr0x@server:~$ tail -n 30 /var/log/auth.log
Dec 26 13:28:01 pve1 pveproxy[1457]: pam_unix(pve:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=192.0.2.44  user=alice
Dec 26 13:28:01 pve1 pveproxy[1457]: authentication failure; rhost=192.0.2.44 user=alice@pam msg=PAM authentication failed

Signification : Confirme que les échecs PAM sont réels (mauvais mot de passe, compte verrouillé, annuaire inaccessible), et non une « bizarrerie 2FA ».

Décision : Si PAM échoue, corrigez la chaîne d’auth Linux (déverrouiller le compte, réinitialiser le mot de passe, santé SSSD) plutôt que de toucher au 2FA Proxmox.

Task 15: Check whether a user is disabled or expired (the quiet lockout)

cr0x@server:~$ pveum user get auditor@pve
userid: auditor@pve
enable: 0
expire: 0

Signification : enable: 0 signifie que le compte est désactivé. Les gens confondent cela avec des échecs 2FA.

Décision : Réactivez si approprié, ou utilisez un autre compte admin. Ne réinitialisez pas le 2FA pour un utilisateur simplement désactivé.

Petite blague #2 : « Je vais juste resserrer l’auth vite fait » est la façon dont on finit par apprendre où sont gardées les clés du datacenter.

Voies de récupération quand vous êtes verrouillé

Il existe deux classes de récupération : corriger le facteur (temps, appareil, enregistrement) ou utiliser le break-glass pour réinitialiser la configuration d’identité. Votre tâche est de choisir la chose la moins invasive qui restaure un accès contrôlé.

Voie de récupération A : TOTP rejeté à cause d’une dérive du temps

C’est le cas le plus heureux. Vous n’avez pas besoin de supprimer le 2FA ; il faut corriger l’heure.

• Corrigez la synchronisation NTP/chrony.
• Ne redémarrez rien à moins que ce soit nécessaire.
• Réessayez la connexion avec un code TOTP frais (ne réutilisez pas le même).

Si la dérive revient, investiguez le BIOS, la source d’horloge de la virtualisation, ou l’accessibilité NTP. La dérive du temps est une cause racine, pas un trait de caractère.

Voie de récupération B : utilisateur a perdu l’appareil d’authentification, mais vous avez une autre session admin

Si un autre admin est connecté, utilisez l’UI ou le CLI pour réinitialiser le 2FA de l’utilisateur. C’est le meilleur cas opérationnel car vous ne changez pas le comportement d’auth global et vous laissez une trace d’audit dans l’historique de config et les logs Proxmox.

Depuis le shell d’un nœud, vous faites typiquement :

• Confirmer l’utilisateur et ses entrées 2FA.
• Désactiver/supprimer les anciens TOTP.
• Exiger une nouvelle inscription et s’assurer que des codes de récupération sont générés et stockés.

Les sous-commandes exactes varient selon la version de Proxmox, mais le flux est constant : identifier, supprimer le facteur cassé, enregistrer un nouveau, tester la connexion, puis nettoyer.

Voie de récupération C : vous ne pouvez pas accéder à l’UI, mais vous avez un shell root (break-glass le plus courant)

Si vous avez root sur un nœud (SSH ou console), vous pouvez réparer les utilisateurs Proxmox et l’état 2FA directement en utilisant pveum et en corrigeant les dépendances de realm sous-jacentes.

Étapes typiques :

1. Vérifier la santé de l’hôte (temps, disque, services).
2. Confirmer quelles identités admin existent (pveum user list, pveum acl list).
3. Si vous n’avez aucun compte admin fonctionnel, créez un utilisateur temporaire @pve avec un mot de passe fort, connectez-vous, puis faites une rotation et restreignez-le.
4. Réinitialisez la configuration 2FA de l’utilisateur affecté.
5. Documentez ce qui s’est passé ; ne laissez pas d’accès d’urgence traîner comme des outils chargés.

Voie de récupération D : vous avez perdu root et le 2FA (maintenance d’hôte)

Si personne ne peut atteindre root (SSH désactivé, console inaccessible, mots de passe inconnus), vous êtes hors du cadre « récupération 2FA Proxmox » et dans « récupération d’accès au serveur ». C’est iDRAC/IPMI, média de secours, et potentiellement la réinitialisation des mots de passe root. C’est aussi un problème de gouvernance : l’entreprise a permis un point de défaillance unique dans l’accès admin.

Ne « résolvez » pas cela en affaiblissant l’auth de façon permanente. Restaurez un accès root contrôlé, puis mettez en place un vrai processus break-glass.

Voie de récupération E : panne de realm externe (LDAP/AD down)

Si les admins s’authentifient via LDAP/AD et que l’annuaire est en panne, vous pouvez être effectivement verrouillé sans implication du 2FA. C’est pourquoi les comptes administrateurs locaux existent. La bonne correction est généralement :

• Utiliser un admin local break-glass (@pve ou root@pam) pour accéder au cluster.
• Réparer le realm externe (routes réseau, confiance TLS, DNS, santé du service).
• Après restauration, envisagez si l’application du realm externe pour tout le monde est souhaitable.

Ce que j’évite pendant la récupération

• Redémarrages de services aléatoires lors d’un incident de cluster. Redémarrer des composants corosync parce que la connexion UI a échoué est de l’opération cargo cult.
• Changements de politique globaux pour désactiver le 2FA pour tous les utilisateurs. C’est un gros marteau tentant avec une longue traînée de regrets.
• Faire ça en live sans témoin pour des modifications à haut risque. Vous voulez une seconde personne pour confirmer que vous n’avez pas supprimé le dernier ACL admin.

Trois mini-récits d’entreprise (comment ça échoue en pratique)

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Dans une entreprise SaaS de taille moyenne, l’équipe de virtualisation a standardisé Proxmox pour les charges internes. Ils avaient un realm d’annuaire externe configuré, et la plupart des utilisateurs s’authentifiaient via LDAP. Ça semblait mature : identité centrale, offboarding cohérent, moins de mots de passe locaux.

L’hypothèse erronée était subtile : ils croyaient que parce que l’UI Proxmox affichait plusieurs admins, il y avait plusieurs admins capables de se connecter pendant une panne d’annuaire. En réalité, chaque compte « admin » était dans le realm externe. Il n’y avait pas d’admin local @pve, et SSH root avait été désactivé au nom du durcissement.

Puis une rotation routine du certificat d’annuaire est arrivée. La chaîne CA a été mise à jour dans la couche d’annuaire, mais les nœuds Proxmox n’ont pas reçu le bundle CA mis à jour. Les binds LDAP ont commencé à échouer. Proxmox n’a pas « partiellement fonctionné ». Il a simplement rejeté toutes les connexions admin, et le support l’a classé à tort comme « 2FA cassé » parce que l’équipe avait récemment imposé le TOTP.

La récupération a pris plus de temps que nécessaire parce qu’ils ont traité cela comme un problème applicatif au lieu d’une dépendance d’identité. Ils ont finalement utilisé l’accès console hors-bande pour se connecter en root localement, mis à jour les stores de confiance, redémarré les bons services, et créé un vrai admin break-glass @pve avec un mot de passe vaulté et accès audité.

Le changement après l’incident n’était pas « moins de sécurité ». C’était une sécurité explicite : si l’identité externe est obligatoire, l’accès d’urgence local doit exister et être testé trimestriellement.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une société financière voulait réduire « l’épandage de crédentiels ». Ils ont décidé de supprimer tous les comptes Linux locaux des nœuds Proxmox et d’exiger tout via des utilisateurs internes Proxmox plus 2FA obligatoire. Ils ont aussi configuré des règles de pare-feu strictes pour que l’UI Web ne soit accessible que depuis un sous-réseau de gestion.

C’était propre. C’était aussi une chaîne fragile : la reachabilité de l’UI dépendait du sous-réseau de gestion, de l’accès VPN, et d’un chemin navigateur fonctionnel. Pendant ce temps, l’accès SSH pour les opérateurs était limité, et les seules personnes pouvant atteindre la console étaient une petite équipe réseau.

Lors d’une fenêtre de maintenance réseau, le concentrateur VPN a eu un incident et l’accès au sous-réseau de gestion a été interrompu pour le personnel distant. Localement au bureau, les quelques personnes présentes n’avaient pas de rôles admin Proxmox parce que « les admins sont des SRE ». Les hôtes de virtualisation allaient bien ; le plan de gestion n’était pas accessible depuis où les admins se trouvaient réellement. L’équipe s’était, en effet, optimisée dans un coin.

La correction n’a pas été d’ouvrir tout. Ils ont conservé le modèle de sous-réseau de gestion mais ajouté un deuxième chemin d’accès physiquement séparé (bastion avec contrôles stricts), documenté les procédures console, et introduit un petit nombre d’admins break-glass sur site avec des clés matérielles stockées dans un casier contrôlé.

La sécurité s’est améliorée, pas l’inverse. La différence était que cela devenait résilient au monde réel, où réseaux et humains échouent parfois simultanément.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une organisation de santé exploitait un cluster Proxmox hébergeant des systèmes départementaux. L’équipe avait un runbook que personne n’aimait : tests trimestriels break-glass. Ils vérifiaient l’accès console hors-bande, confirmaient qu’un admin local @pve pouvait se connecter, validaient la présence des codes de récupération, et vérifiaient qu’au moins deux personnes avaient la permission d’accéder au coffre.

Un jour, le téléphone d’un admin a été effacé par une modification de politique MDM. Cet admin était aussi la personne qui faisait la plupart du travail de virtualisation, et son compte Proxmox avait le TOTP obligatoire. Mauvais timing. L’UI Web a rejeté sa connexion. Son appareil TOTP de secours ? Également géré par la même politique MDM. Double mauvais timing.

Ils n’ont pas paniqué. L’ingénieur d’astreinte a suivi le runbook : s’est connecté avec le compte break-glass, a confirmé la santé du cluster, a réinitialisé la configuration 2FA de l’utilisateur affecté, et a exigé une réinscription avec un second facteur immédiatement. Le ticket d’incident s’est fermé avant de pouvoir muter en « grosse panne », parce que ça n’en est jamais devenu une.

Le compte rendu post-incident était ennuyeux aussi : « Test break-glass réussi ; mettre à jour la politique MDM pour éviter l’effacement simultané des facteurs ; rappeler aux admins de garder les codes de récupération hors ligne. » En exploitation production, l’ennui est le plus grand compliment.

Erreurs courantes : symptôme → cause racine → correctif

1) Symptôme : « Code TOTP invalide » pour tout le monde

Cause racine : dérive de l’horloge du nœud ou NTP non synchronisé.

Correctif : restaurez la synchronisation temporelle (chrony/ntp), vérifiez que timedatectl indique synchronisé, puis réessayez avec un code frais.

2) Symptôme : seuls les utilisateurs @pam ne peuvent pas se connecter ; les @pve fonctionnent

Cause racine : problème PAM/NSS : utilisateur manquant, mot de passe changé, SSSD/LDAP inaccessible, ou compte verrouillé.

Correctif : validez avec getent passwd et les logs d’auth ; corrigez la chaîne d’auth Linux, ou utilisez un admin local @pve pour continuer à opérer.

3) Symptôme : UI Web inaccessible, mais SSH fonctionne

Cause racine : pveproxy en panne, problème TLS, règle firewall, ou disque plein empêchant les services.

Correctif : vérifiez systemctl status pveproxy, inspectez les logs, libérez de l’espace, redémarrez seulement le service en échec.

4) Symptôme : la connexion fonctionne sur un nœud mais pas sur un autre

Cause racine : incohérence de cluster, problèmes de quorum, ou défaillance de service spécifique au nœud.

Correctif : vérifiez pvecm status pour l’état de quorum et rétablissez la santé du cluster ; évitez de faire des changements d’auth pendant une partition.

5) Symptôme : les utilisateurs LDAP échouent après une « mise à jour mineure de certificat »

Cause racine : chaîne CA manquante sur les nœuds Proxmox ou validation TLS plus stricte.

Correctif : mettez à jour le bundle CA de confiance sur les nœuds, vérifiez la config du realm, puis testez les binds et connexions.

6) Symptôme : comportement « utilisateur désactivé » pris pour un verrouillage 2FA

Cause racine : compte enable: 0 ou expiré.

Correctif : inspectez l’état utilisateur avec pveum user get, réactivez si autorisé, et validez les ACL.

7) Symptôme : vous réinitialisez le 2FA et ne pouvez toujours pas vous connecter

Cause racine : mauvais realm sélectionné à la connexion ou identifiant incorrect (ex. tenter alice au lieu de alice@pam).

Correctif : vérifiez l’ID exact de l’utilisateur et le realm ; assurez-vous que le formulaire de connexion a le bon realm.

8) Symptôme : l’auth échoue seulement depuis certains réseaux

Cause racine : interférence firewall/WAF/proxy, port 8006 bloqué, ou interception TLS cassant la session.

Correctif : confirmez le chemin réseau et la gestion des certificats ; testez depuis le sous-réseau de gestion et depuis le nœud lui-même.

Listes de contrôle / plans pas à pas

Checklist A: Avant d’activer ou d’imposer le 2FA (faites-le une fois, bien)

1. Créez deux utilisateurs admin avec des facteurs indépendants (deux téléphones, ou téléphone + clé matérielle).
2. Générez et stockez les codes de récupération hors ligne sous accès contrôlé.
3. Confirmez le chemin d’accès root@pam : console et/ou SSH via bastion. Documentez-le.
4. Vérifiez la synchronisation temporelle sur chaque nœud (timedatectl, chronyc tracking).
5. Vérifiez qu’au moins un compte admin n’est pas dépendant d’un LDAP/AD externe si vous ne pouvez pas garantir la disponibilité de l’annuaire.
6. Exécutez un test break-glass : déconnectez-vous, puis reconnectez-vous en utilisant l’admin de secours et un facteur différent.
7. Rédigez le rollback : quelles commandes vous exécuterez pour supprimer un facteur cassé et rétablir l’accès.

Checklist B: Si vous suspectez un verrouillage (confinement d’abord)

1. Arrêtez de changer des choses. Déterminez si c’est connectivité, santé des services, ou auth.
2. Vérifiez la synchronisation temporelle et l’espace disque sur un nœud.
3. Vérifiez pveproxy/pvedaemon statut et logs pour des messages d’erreur d’auth précis.
4. Identifiez quel realm échoue (@pam vs @pve vs LDAP).
5. Essayez de vous connecter avec un admin connu bon depuis un chemin réseau connu bon.
6. N’utilisez le shell root break-glass que si nécessaire ; gardez les changements minimes et réversibles.

Checklist C: Réinitialisation 2FA contrôlée pour un utilisateur (la méthode sûre)

1. Confirmez l’ID utilisateur et le realm avec pveum user list.
2. Confirmez que l’utilisateur a les ACL requises ; ne réinitialisez pas le 2FA de la mauvaise personne.
3. Capturez des preuves : lignes de logs pertinentes montrant la raison de l’échec.
4. Désactivez/supprimez le second facteur cassé de l’utilisateur via les outils de gestion d’utilisateur Proxmox.
5. Faites réenregistrer l’utilisateur immédiatement, idéalement avec deux facteurs.
6. Générez/stockez à nouveau les codes de récupération si applicable.
7. Confirmez que l’utilisateur peut se connecter et effectuer l’action admin minimale nécessaire.
8. Clôturez la boucle : documentez ce qui s’est passé et comment éviter la répétition (politique MDM, clé de secours, etc.).

Checklist D: Renforcement post-récupération (ne laissez pas de désordre)

1. Faites tourner tous les mots de passe d’urgence utilisés pendant l’incident.
2. Revoyez les ACL : assurez-vous qu’il y a au moins deux admins valides.
3. Reconfirmez la synchronisation temporelle et les alertes de monitoring.
4. Auditez les logs pour tentatives de connexion suspectes pendant la fenêtre.
5. Planifiez un test break-glass dans la semaine — validez que votre « correctif » n’a pas créé un nouveau chemin fragile.

FAQ

1) Le 2FA de Proxmox est-il stocké par nœud ou cluster-wide ?

Dans un cluster, la configuration Proxmox est effectivement partagée ; la configuration des utilisateurs et d’auth devrait être cohérente. Traitez les changements 2FA comme ayant un impact sur le cluster et vérifiez le quorum avant de les faire.

2) Quel est le type de compte « break-glass » le plus sûr : @pve ou @pam ?

@pve est généralement plus sûr pour l’indépendance de la gestion des utilisateurs OS et des problèmes d’annuaire/NSS externes. Mais vous avez toujours besoin d’un shell root pour de véritables opérations break-glass.

3) Une dérive du temps peut-elle réellement provoquer un verrouillage total ?

Oui. La validation TOTP se base sur des fenêtres temporelles. Si votre nœud est suffisamment décalé, chaque code correct sera rejeté. Corrigez le temps avant de réinitialiser des facteurs.

4) Si LDAP est en panne, pourquoi cela ressemble-t-il à un problème 2FA ?

Parce que l’UI voit juste « authentication failed ». Les utilisateurs supposent alors que leur code est erroné. Les logs révèlent généralement des échecs de bind ou des erreurs PAM/NSS.

5) Dois-je désactiver le 2FA globalement pendant un incident ?

Presque jamais. Désactivez ou réinitialisez pour l’utilisateur affecté uniquement, et seulement après avoir confirmé que l’échec n’est pas dû à la synchronisation temporelle ou à une dépendance de realm. La désactivation globale est un incident de sécurité en devenir.

6) Que faire si je ne peux pas atteindre l’UI Web mais que je peux atteindre le nœud via SSH ?

C’est un problème de service ou de chemin réseau, pas un problème 2FA. Vérifiez pveproxy et l’espace disque, puis redémarrez les services minimaux requis.

7) Combien d’admins devraient avoir un accès break-glass ?

Minimum deux, idéalement trois dans les organisations plus larges, avec accès au coffre audité. Un seul est un point unique de défaillance. Dix est un problème de contrôle d’accès.

8) Les codes de récupération réduisent-ils la sécurité ?

Ils réduisent le risque opérationnel s’ils sont stockés correctement. Stockés de façon inappropriée (notes en clair, chat partagé) ils réduisent absolument la sécurité. La méthode de stockage est la frontière de sécurité.

9) Quel est le plus grand anti-pattern opérationnel avec le 2FA dans Proxmox ?

Imposer le 2FA sans valider l’accès hors-bande et sans un second admin possédant un facteur différent. Ce n’est pas un renforcement ; c’est du jeu.

Conclusion : prochaines étapes à faire aujourd’hui

Si vous exploitez Proxmox en production, traitez le 2FA comme faisant partie de la conception de disponibilité, pas seulement de votre posture de sécurité. Les verrouillages se produisent à l’intersection des humains, du temps et de la plomberie d’identité. Vous ne les empêchez pas par l’espoir. Vous les empêchez par la redondance et la répétition.

Faites ceci ensuite, dans cet ordre :

1. Vérifiez la synchronisation temporelle sur chaque nœud et surveillez la dérive.
2. Assurez-vous d’avoir au moins deux identités Administrator, avec des seconds facteurs indépendants.
3. Stockez les codes de récupération hors ligne sous accès contrôlé et testez que vous pouvez les récupérer hors urgence.
4. Confirmez que l’accès console hors-bande fonctionne et est documenté.
5. Exécutez un exercice break-glass trimestriel et traitez les échecs comme de vrais incidents.

L’objectif n’est pas « ne jamais être verrouillé ». L’objectif est de rendre la récupération prévisible, auditable et rapide — pour que la sécurité ne devienne pas une panne.