Proxmox « Échec de connexion » lorsque l’interface Web se charge : principales causes et correctifs

janvier 1, 2026 • février 3, 2026 • Lecture : 26 min • Views: 12

Cet article vous a aidé ?

Vous pouvez pinguer l’hôte. L’interface Web se charge. L’avertissement de certificat est le classique « on s’en occupera plus tard ». Puis vous tapez le mot de passe que vous avez tapé mille fois et vous obtenez la réponse laconique : Échec de connexion.

C’est le genre d’erreur qui fait perdre du temps parce que ça ressemble à un simple problème de mot de passe. Parfois c’en est un. Souvent non. L’interface n’est que le messager, et elle n’explique pas très bien ce qui a réellement cassé. Faisons en sorte qu’elle s’explique.

Guide de diagnostic rapide (faire d’abord)

Si vous voulez le chemin le plus rapide vers la cause réelle, vous cherchez l’une des trois choses suivantes : mauvais realm, problèmes de temps/ticket, ou échec de l’authentification côté backend. Ne commencez pas par redémarrer des services au hasard. Lisez d’abord les erreurs.

Étape 1 — Confirmez que vous utilisez le bon realm

Si vous vous connectez en tant que root, dans la plupart des déploiements vous voulez Realm = PAM, donc le nom d’utilisateur devrait ressembler à root@pam.
Si vous avez LDAP/AD configuré, vous devrez peut‑être utiliser user@yourrealm. L’interface se souvient de votre dernier realm sélectionné, ce qui est pratique jusqu’à ce que ça ne le soit pas.

Étape 2 — Regardez les erreurs d’authentification là où elles se trouvent réellement

Ouvrez un shell (console, IPMI, ou SSH si c’est encore possible).
Suivez les logs pendant que vous tentez une connexion. Si vous voyez « authentication failure » avec des détails, vous êtes déjà en avance sur l’UI.

Étape 3 — Vérifiez la dérive horaire (le tueur silencieux)

Si l’horloge du nœud est fausse, des tickets peuvent être émis puis immédiatement rejetés comme expirés ou non encore valides. Cela se manifeste par « Échec de connexion » même avec des identifiants parfaits.

Étape 4 — Vérifiez que pveproxy et pvedaemon ne sont pas bloqués ou mal configurés

L’interface n’est que du JavaScript parlant à pveproxy (API) et associés. Si les services sont mécontents, vous obtiendrez des échecs génériques.

Étape 5 — Si c’est un cluster, testez depuis un autre nœud

Dans un cluster, la configuration d’authentification et la base d’utilisateurs sont partagées via /etc/pve (pmxcfs). Si pmxcfs est instable sur un nœud, il peut afficher l’UI mais se comporter de façon étrange pour l’authentification et les permissions.

Une vérité opérationnelle : si vous ne pouvez pas vous connecter, ne discutez pas avec l’interface graphique. Interrogez le démon. Il finira par vous dire, si vous l’écoutez.

L’interface Web de Proxmox VE est un client pour l’API REST. Le flux de connexion est à peu près :

Le navigateur charge l’UI depuis pveproxy (port 8006).
Vous soumettez username@realm et mot de passe (et possiblement la 2FA).
pveproxy transmet l’authentification au backend de realm sélectionné (PAM, PVE, LDAP/AD, OpenID, etc.).
En cas de succès, Proxmox émet un ticket (cookie) et un jeton CSRF pour les appels API.
L’UI utilise ce ticket et ce jeton CSRF pour les opérations suivantes.

Cela importe car « Échec de connexion » n’est pas une seule chose. Cela peut signifier :

Le backend du realm a rejeté les identifiants (problème réel de mot de passe/2FA).
Le backend est injoignable (LDAP en panne, problème TLS AD, échec DNS).
Le ticket a été créé mais le navigateur ne peut pas le stocker (décalage horaire, bizarreries de cookie, problèmes d’en-têtes du reverse proxy).
Le nœud ne peut pas lire sa propre configuration d’authentification (problèmes pmxcfs, permissions dans /etc/pve).

Voici un modèle mental utile : l’UI se charge signifie que TCP + TLS + disponibilité basique du service sont OK. La connexion fonctionne signifie que le backend d’authentification, le temps et la gestion d’état des tickets sont également OK. Couches différentes. Modes de défaillance différents.

Faits et contexte intéressants (pourquoi ces pannes arrivent)

Fait 1 : Le système de fichiers de cluster de Proxmox VE (pmxcfs) est implémenté comme un système FUSE et est soutenu par corosync pour la distribution. Lorsqu’il est instable, des « simples fichiers » comme la configuration utilisateur ne sont plus si simples.
Fait 2 : Le port par défaut de l’UI/API Proxmox est le 8006, historiquement choisi pour éviter les collisions avec des serveurs web et appliances utilisant déjà 443/8443.
Fait 3 : Proxmox distingue les utilisateurs PAM (comptes système), PVE (stockés dans la base Proxmox) et les realms externes comme LDAP/AD/OIDC. Choisir le mauvais est la blessure auto-infligée n°1.
Fait 4 : L’authentification par ticket dépend implicitement de la justesse de l’heure. Les systèmes modernes détestent la dérive d’horloge car elle casse la protection contre la relecture.
Fait 5 : De nombreux composants Proxmox sont basés sur Perl (notamment pveproxy et pvedaemon), ce qui signifie que les logs peuvent être très explicites si vous prenez la peine de les lire.
Fait 6 : Dans les configurations en cluster, /etc/pve n’est pas « juste une config locale ». C’est un magasin d’état distribué. Si corosync n’a pas le quorum, les lectures/écritures de config peuvent se comporter différemment de ce que vous attendez.
Fait 7 : Les problèmes côté navigateur existent : cookies obsolètes, JS mis en cache et extensions de confidentialité agressives peuvent casser l’échange CSRF/jeton et ressembler à « Échec de connexion ». Rare, mais réel.
Fait 8 : L’UI Proxmox a historiquement utilisé ExtJS. Beaucoup de comportements front-end (y compris certains traitements d’erreur) ont été façonnés par les hypothèses de cet écosystème sur les sessions et les jetons.

Principales causes quand l’UI se charge mais que vous ne pouvez pas vous connecter

1) Mauvais realm (PAM vs PVE vs LDAP/AD vs OIDC)

L’UI se souvient de votre dernier realm. C’est pratique jusqu’à ce que vous passiez d’un utilisateur LDAP à root et oubliiez de le remettre. Résultat : vous essayez root contre LDAP, ça échoue, et l’UI hausse les épaules.

Indice de diagnostic : Si root a « soudainement » arrêté de fonctionner après que vous ayez ajouté un realm LDAP, c’est la première chose que je vérifie. La plupart des ruptures d’authentification « soudaines » sont en réalité un état de l’UI.

2) Dérive horaire ou NTP en panne (les tickets deviennent invalides)

La dérive horaire ne se présente pas toujours comme « ticket expiré ». Parfois c’est juste « Échec de connexion ». Si la pile RTC est faible ou que votre NTP est bloqué, vous pouvez avoir une dérive suffisante pour casser les sessions, la validation TLS et la coordination du cluster.

3) PAM échoue (compte verrouillé, expiré, ou problèmes NSS)

L’authentification PAM peut échouer pour des raisons autres que « mauvais mot de passe » :

Compte verrouillé (pam_tally2 / faillock).
Mot de passe expiré (surtout si vous avez appliqué des politiques sur des comptes système).
Problèmes de résolution NSS (étrange si vous avez branché LDAP pour les comptes système).

4) Incompatibilité 2FA ou base temporelle défaillante

TOTP est basé sur le temps. Si l’horloge du serveur est fausse, votre 2FA est invalide. Si vous utilisez WebAuthn, le comportement du navigateur et du reverse proxy compte. Et si l’UI demande « OTP » mais que vous saisissez le mot de passe+OTP dans un format incorrect pour ce realm, ça échouera sans beaucoup d’indications.

5) Problèmes `pveproxy` / `pvedaemon` (service instable ou bloqué)

Oui, l’UI peut se charger même si le backend a des pannes partielles. Vous pouvez obtenir du contenu statique et toujours voir échouer les appels API d’authentification. Les redémarrages de services peuvent aider, mais traitez-les comme des pansements : utiles, pas curatifs.

6) Incompatibilité certificat/clé après restauration ou changement d’hôte/IP

Si vous avez restauré un nœud depuis une sauvegarde, cloné une VM en une nouvelle identité, ou changé le hostname sans nettoyer, vous pouvez vous retrouver avec des certificats incompatibles ou une identité de nœud obsolète. Ça peut empirer dans les clusters.

7) Système de fichiers de cluster (`/etc/pve`) non monté/instable

Si /etc/pve est instable, la config utilisateur et les realms peuvent ne pas être lisibles comme prévu. Le nœud peut toujours servir l’UI parce que le service démarre, mais la logique d’authentification peut ne pas trouver ce dont elle a besoin.

8) Échec du realm d’authentification externe (LDAP/AD, OIDC)

Les pannes LDAP/AD sont classiques : mauvaise résolution DNS, problèmes de chaîne TLS, mot de passe du bind expiré, firewall, ou une fenêtre de maintenance d’un contrôleur de domaine dont personne ne vous a parlé.

9) Bizarreries navigateur/cookie/CSRF (moins courant, mais réel)

Quand l’UI se charge mais que vous voyez immédiatement « Échec de connexion » après avoir saisi des identifiants corrects, essayez une fenêtre de navigation privée ou un autre navigateur. Si cela corrige, vous n’avez pas résolu Proxmox ; vous avez résolu l’état côté client.

Blague #1 : Si votre plan d’intervention est « vider le cache du navigateur », vous n’avez pas de plan—vous avez un rituel.

Tâches pratiques : commandes, sorties et décisions (12+)

Voici les actions que j’exécute réellement sur un nœud quand l’UI se charge mais que l’authentification échoue. Chaque tâche inclut une commande, ce que signifie une sortie typique, et la décision suivante. Exécutez-les sur l’hôte Proxmox sauf indication contraire.

Task 1 — Confirmer que les services tournent : pveproxy et pvedaemon

cr0x@server:~$ systemctl status pveproxy pvedaemon --no-pager
● pveproxy.service - PVE API Proxy Server
     Loaded: loaded (/lib/systemd/system/pveproxy.service; enabled)
     Active: active (running) since Tue 2025-12-23 09:11:04 UTC; 2h 18min ago
● pvedaemon.service - PVE API Daemon
     Loaded: loaded (/lib/systemd/system/pvedaemon.service; enabled)
     Active: active (running) since Tue 2025-12-23 09:11:02 UTC; 2h 18min ago

Signification : Si l’un des deux n’est pas actif, l’authentification sera peu fiable ou inexistante.

Décision : Si non lancé, vérifiez les logs (Task 2) avant de redémarrer. S’ils tournent, passez aux vérifications realm/heure.

Task 2 — Suivre le journal du proxy pendant une tentative de connexion

cr0x@server:~$ journalctl -u pveproxy -f
Dec 23 11:29:31 pve pveproxy[2154]: authentication failure; rhost=192.0.2.55 user=root@pam msg=failed to authenticate user
Dec 23 11:29:31 pve pveproxy[2154]: client denied: invalid credentials

Signification : « invalid credentials » pointe vers realm/mot de passe/2FA ou verrous PAM.

Décision : Si vous voyez un mismatch de realm ou des erreurs LDAP, sautez à la section concernée. Si vous voyez des erreurs de ticket/CSRF, allez aux vérifications de l’heure et des cookies.

Task 3 — Suivre pvedaemon pour des erreurs d’authentification/permissions plus profondes

cr0x@server:~$ journalctl -u pvedaemon -n 200 --no-pager
Dec 23 11:29:31 pve pvedaemon[2031]: authentication failure; user=root@pam msg=pam_authenticate failed: Authentication failure

Signification : Rejet au niveau backend (PAM dans cet exemple).

Décision : Enquêter sur l’état PAM/compte (Tasks 9–11). Si pvedaemon affiche « permission denied reading /etc/pve », investigatez pmxcfs (Tasks 6–7).

Task 4 — Vérifier l’heure du nœud et la synchronisation NTP

cr0x@server:~$ timedatectl
               Local time: Tue 2025-12-23 11:31:08 UTC
           Universal time: Tue 2025-12-23 11:31:08 UTC
                 RTC time: Tue 2025-12-23 11:31:07
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: no

Signification : « System clock synchronized: no » est suspect, surtout dans des clusters ou avec la 2FA.

Décision : Réparez la synchronisation horaire avant toute autre action. Si l’heure est décalée de plusieurs minutes, attendez-vous à des échecs de ticket et à des problèmes corosync aussi.

Task 5 — Vérifier l’état de chrony (commun sur Debian)

cr0x@server:~$ chronyc tracking
Reference ID    : 203.0.113.10 (ntp1.example)
Stratum         : 3
Ref time (UTC)  : Tue Dec 23 11:30:58 2025
System time     : 0.842123 seconds slow of NTP time
Last offset     : -0.001993812 seconds
RMS offset      : 0.012340123 seconds
Frequency       : 12.345 ppm fast
Leap status     : Normal

Signification : De petits offsets sont tolérables. De grands offsets et « Leap status: Not synchronised » ne le sont pas.

Décision : Si non synchronisé, vérifiez firewall/DNS et vos serveurs NTP. Si vous êtes en cluster, corrigez l’heure sur tous les nœuds.

Task 6 — Confirmer que pmxcfs est monté et sain

cr0x@server:~$ mount | grep /etc/pve
pmxcfs on /etc/pve type fuse.pmxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)

Signification : Si cela manque, la configuration du cluster Proxmox n’est pas montée ; les realms et utilisateurs peuvent se comporter de manière étrange.

Décision : Vérifiez pve-cluster et corosync (Task 7). Dans une installation mono‑nœud, pmxcfs doit quand même être monté.

Task 7 — Vérifier le statut du cluster/quorum (nœuds en cluster)

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

Quorum information
------------------
Date:             Tue Dec 23 11:33:12 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.3a
Quorate:          Yes

Signification : Si Quorate: No, les lectures/écritures de config peuvent être restreintes et les symptômes incluent un comportement étrange d’authentification selon ce qui est en panne.

Décision : Réparez le réseau corosync, la connectivité des nœuds et le quorum. Ne « redémarrez juste jusqu’à ce que ça marche » — c’est comme transformer un hoquet en indisponibilité.

Task 8 — Lister les realms et vérifier lesquels existent

cr0x@server:~$ pveum realm list
Realm        Type    Comment
pam          pam
pve          pve
corp-ldap    ldap    Corporate LDAP

Signification : Si le realm que vous sélectionnez dans l’UI n’est pas là (ou a été renommé), votre tentative de connexion est vouée à l’échec.

Décision : Utilisez un realm connu‑bon (souvent pam) pour un accès break‑glass, puis réparez les realms externes.

Task 9 — Valider que le compte root n’est pas verrouillé au niveau OS

cr0x@server:~$ passwd -S root
root P 2025-11-04 0 99999 7 -1

Signification : Le statut P indique généralement qu’un mot de passe utilisable est configuré. L indique verrouillé.

Décision : Si verrouillé, déverrouillez intentionnellement (Task 10). Si le mot de passe est expiré, définissez‑en un nouveau de manière contrôlée.

Task 10 — Déverrouiller root (si vous en prenez la responsabilité) et définir un mot de passe

cr0x@server:~$ passwd -u root
passwd: password expiry information changed.

Signification : Root est déverrouillé. C’est une décision de sécurité, pas seulement technique.

Décision : Si votre politique interdit les connexions root, ne faites pas ça à la légère. Utilisez plutôt un utilisateur admin dans le realm PVE ou réparez votre fournisseur d’identité.

Task 11 — Tester l’authentification PAM directement (sans l’UI)

cr0x@server:~$ pamtester login root authenticate
Password:
pamtester: successfully authenticated

Signification : Si l’authentification PAM réussit ici mais échoue dans l’UI, le problème peut être la sélection du realm, les attentes 2FA, ou des problèmes de ticket/cookie/heure.

Décision : Si PAM échoue ici aussi, vous avez un problème d’authentification OS (mot de passe, verrouillage, modifications de la pile PAM).

Task 12 — Vérifier la base d’utilisateurs Proxmox (realm PVE)

cr0x@server:~$ pveum user list
UserID         Enable Expire
root@pam       1
admin@pve      1
ops@corp-ldap  1

Signification : Si votre utilisateur admin est désactivé ou expiré, la connexion UI échoue même si LDAP est OK.

Décision : Activez/prolongez le bon utilisateur. Si l’utilisateur est externe, assurez‑vous que le realm est joignable.

Task 13 — Vérifier si la 2FA est appliquée pour l’utilisateur

cr0x@server:~$ pveum user get admin@pve
┌─────────────┬──────────┐
│ key         │ value    │
╞═════════════╪══════════╡
│ enable      │ 1        │
│ expire      │ 0        │
│ firstname   │          │
│ lastname    │          │
│ email       │          │
│ keys        │          │
│ groups      │          │
│ tokens      │          │
│ totp        │ 1        │
└─────────────┴──────────┘

Signification : Si TOTP est activé (ou requis par une politique), les connexions par mot de passe seul échouent. Certains utilisateurs oublient qu’ils l’ont activé il y a des mois.

Décision : Utilisez le flux OTP correct, ou désactivez temporairement la 2FA seulement si vous avez une procédure formelle de break‑glass.

Task 14 — Vérifier que l’API répond localement (isoler réseau vs authentification)

cr0x@server:~$ curl -k -s https://127.0.0.1:8006/api2/json/version | sed 's/[{}]//g'
"data":"release":"8.2","repoid":"a1b2c3d4"

Signification : Si cela échoue localement, vous n’avez pas un « problème de navigateur ». Vous avez un problème de service (pveproxy down, TLS, ou firewall local).

Décision : Réparez pveproxy/listeners avant de chasser les realms.

Task 15 — Essayer une requête de ticket API basée sur le mot de passe (isole l’UI)

cr0x@server:~$ curl -k -s -d "username=root@pam&password=CorrectHorseBatteryStaple" https://127.0.0.1:8006/api2/json/access/ticket | head
{"data":{"username":"root@pam","ticket":"PVE:root@pam:...","CSRFPreventionToken":"b0c1..."}}

Signification : Si cela fonctionne, le chemin d’authentification backend est OK ; l’UI/cookies/reverse proxy peut être en cause.

Décision : Vérifiez les cookies du navigateur, les en‑têtes du reverse proxy et la validité temporelle. Si cela échoue, relisez les logs avec la Task 2.

Task 16 — Vérifier les problèmes d’en-têtes du reverse proxy (si vous placez Proxmox derrière)

cr0x@server:~$ grep -R "proxy_set_header" -n /etc/nginx/sites-enabled 2>/dev/null | head
/etc/nginx/sites-enabled/pve.conf:12:    proxy_set_header Host $host;
/etc/nginx/sites-enabled/pve.conf:13:    proxy_set_header X-Forwarded-Proto https;
/etc/nginx/sites-enabled/pve.conf:14:    proxy_set_header X-Forwarded-For $remote_addr;

Signification : Des en‑têtes Host ou proto manquants/incorrects peuvent casser le scope des cookies, les redirections, et parfois le flux d’authentification.

Décision : Assurez‑vous que votre reverse proxy est configuré spécifiquement pour Proxmox et prend en charge WebSockets. Si vous n’avez pas besoin d’un reverse proxy, n’en ajoutez pas un « pour l’esthétique ».

Task 17 — Inspecter rapidement les règles de firewall locales

cr0x@server:~$ pve-firewall status
Status: enabled/running

Signification : Un firewall mal configuré peut bloquer LDAP/AD ou NTP tout en laissant passer 8006, produisant « Échec de connexion » pour les realms externes.

Décision : Si les realms externes échouent, confirmez l’accès sortant vers LDAP/DC/NTP.

Task 18 — Valider la connectivité du realm LDAP (quand LDAP/AD est impliqué)

cr0x@server:~$ pveum realm sync corp-ldap
syncing users and groups...
ERROR: LDAP connection failed: Can't contact LDAP server

Signification : L’identité externe est down ou injoignable depuis cet hôte (DNS, routage, firewall, TLS, serveur down).

Décision : Réparez d’abord le réseau/DNS/TLS. Ne « corrigez » pas ça en créant des utilisateurs locaux sauf si vous suivez un plan de break‑glass documenté.

Trois mini-récits d’entreprise (comment les équipes se font piéger)

Mini‑récit 1 : L’incident causé par une fausse hypothèse

L’entreprise avait un cluster Proxmox soigné : trois nœuds, stockage partagé, et LDAP intégré « à la manière entreprise ». L’équipe a onboardé un nouvel ingénieur d’astreinte et a fait le classique : « Connectez‑vous avec votre compte LDAP. »

Un mois plus tard, lors d’un incident de stockage, l’équipe LDAP a effectué une maintenance planifiée des contrôleurs de domaine. C’était censé être transparent. Ce ne l’était pas. Un DC est revenu avec une chaîne de certificats ancienne, l’autre avait du lag de réplication, et le load balancer a fait des choix créatifs. L’interface Web Proxmox se chargeait partout, mais les connexions LDAP échouaient.

L’ingénieur d’astreinte a essayé root ensuite. Toujours échoué. Ils ont supposé que le mot de passe root avait été changé ou perdu et ont escaladé vers la sécurité. Pendant ce temps, le problème de stockage s’aggravait parce que personne ne pouvait changer les limites IO des VM ou migrer des charges.

La vraie cause était cruellement petite : le formulaire de connexion était réglé sur le realm LDAP, et l’ingénieur a tapé root sans @pam. Proxmox a fait exactement ce qu’on lui demandait : authentifier root contre LDAP. Aucun tel utilisateur, aucune connexion.

Ils ont corrigé la sélection du realm, se sont connectés en tant que root@pam, et ont stabilisé le cluster. L’action post‑mortem n’a pas été « former mieux ». Ce fut de créer un utilisateur administrateur break‑glass local dans le realm PVE, avec récupération 2FA testée, et d’inclure « vérifier le menu realm » dans le runbook. Ennuyeux. Efficace.

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

Une autre organisation a mis Proxmox derrière un reverse proxy corporate. L’objectif : point d’entrée unique, journalisation WAF, et « TLS cohérent ». Tout raisonnable. Puis quelqu’un a optimisé la config du proxy pour appliquer des politiques de cookies agressives et a durci la gestion des en‑têtes parce que l’outil de conformité signalait des « défauts non sécurisés ».

Le lundi, les utilisateurs ont signalé des « échecs de connexion » intermittents. L’UI se chargeait bien. Parfois ça fonctionnait après un rafraîchissement ; parfois non. Les ingénieurs ont redémarré pveproxy sur deux nœuds et ont « temporairement » corrigé le problème, ce qui leur a donné confiance et leur a fait perdre du temps.

La défaillance venait de la gestion des en‑têtes et des cookies par le reverse proxy. Dans certaines conditions, le proxy changeait le schéma/hôte perçu, Proxmox émettait des cookies avec des attributs que le navigateur refusait, et l’échange CSRF/jeton échouait. L’UI n’avait qu’un avis : « Échec de connexion ».

La correction fut de cesser d’être trop astucieux. Le proxy a été reconfiguré pour transmettre correctement Host et X-Forwarded-Proto, préserver les en‑têtes d’upgrade WebSocket, et ne pas déformer les attributs des cookies. Après cela, les connexions sont redevenues ennuyeuses—exactement ce qu’on attend de l’authentification.

Mini‑récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la journée

Une équipe gérant Proxmox pour l’intégration continue interne avait l’habitude qui semblait paranoïaque : chaque trimestre ils validaient une connexion break‑glass sur chaque cluster. Pas un « on pense que ça marche », mais un vrai test de connexion depuis la console et l’UI, avec checklist enregistrée.

Un jour, leur upstream NTP a changé et une mise à jour de règle firewall a bloqué le NTP sortant sur un VLAN. Un seul nœud Proxmox a dérivé. Pas assez pour paniquer — juste assez pour rendre les tickets d’authentification fragiles. L’UI se chargeait, les connexions échouaient parfois, et les sessions tombaient aléatoirement.

Leur monitoring a pris le décalage horaire, mais la vraie victoire fut procédurale : le runbook commençait par vérifier timedatectl et chronyc tracking. Ils ont corrigé la règle firewall, forcé une mise à l’heure, et le problème a disparu.

Pas d’héroïsme. Pas de réinitialisations de mot de passe d’urgence. Pas de « peut‑être Proxmox est cassé ». Juste un système qui se comporte de façon prévisible et une équipe qui refuse d’improviser des correctifs d’authentification en production.

Idée paraphrasée (Gene Kranz) : « L’échec n’est pas une option » parle en réalité de discipline — de bons systèmes et des procédures calmes réduisent l’espace où l’échec peut se produire.

Erreurs fréquentes : symptôme → cause racine → correctif

Cette section est volontairement spécifique. Si vous pouvez mapper votre symptôme à une ligne, vous pouvez arrêter de deviner.

1) « Le mot de passe root marche forcément » mais la connexion échoue immédiatement

Symptôme : L’UI se charge, le mot de passe est rejeté instantanément, pas d’invite OTP.
Cause racine : Realm incorrect sélectionné (souvent realm LDAP) donc root est authentifié contre le mauvais backend.
Correctif : Connectez‑vous en tant que root@pam avec le Realm « Linux PAM standard authentication ». Confirmez les realms avec pveum realm list.

2) La connexion échoue uniquement pour les utilisateurs LDAP/AD ; les locaux fonctionnent toujours

Symptôme : root@pam fonctionne ; user@corp-ldap non.
Cause racine : Connectivité LDAP/TLS/DNS/firewall, mot de passe du bind expiré, ou maintenance DC.
Correctif : Lancez pveum realm sync corp-ldap et inspectez les erreurs. Vérifiez DNS et egress firewall. Réparez la chaîne de confiance si vous utilisez LDAPS.

3) La connexion fonctionnait hier ; aujourd’hui elle échoue sur plusieurs nœuds

Symptôme : Plusieurs utilisateurs rapportent « Échec de connexion » avec des mots de passe corrects.
Cause racine : Dérive horaire (NTP cassé), ou panne du backend de realm (LDAP/OIDC down).
Correctif : Vérifiez timedatectl et l’état NTP. Si realm externe, testez la connectivité depuis les nœuds. Réparez l’heure d’abord, puis l’identité.

4) La connexion réussit, puis l’UI agit comme si vous étiez déconnecté

Symptôme : Vous vous « connectez », puis vous êtes renvoyé ou les actions échouent avec des erreurs de permission.
Cause racine : Cookie non stocké/renvoyé à cause d’un reverse proxy ou de paramètres de confidentialité du navigateur ; parfois mismatch du token CSRF dû à une confusion scheme/host.
Correctif : Essayez l’accès direct à https://node:8006. Essayez un profil navigateur propre. Corrigez les en‑têtes du reverse proxy et les réglages WebSocket.

5) L’UI du nœud de cluster se charge, mais la connexion ne marche que sur certains nœuds

Symptôme : Le nœud A accepte la connexion, le nœud B la rejette, même utilisateur.
Cause racine : Dérive horaire au niveau nœud, problèmes de montage pmxcfs, ou partition corosync partielle causant une config obsolète/partielle.
Correctif : Comparez l’heure et pvecm status. Vérifiez le montage de /etc/pve. Réparez le transport du cluster et rétablissez le quorum.

6) « Échec de connexion » après activation de la 2FA

Symptôme : Le mot de passe était accepté auparavant ; maintenant ça échoue toujours.
Cause racine : OTP requis mais non fourni/saisi correctement ; dérive horaire serveur invalide l’OTP.
Correctif : Réparez la synchronisation horaire. Confirmez le statut 2FA avec pveum user get USER. Utilisez les méthodes de récupération prévues par la politique ; n’en inventez pas sous pression.

7) Après une restauration/clone, personne ne peut se connecter (ou l’UI se comporte de façon incohérente)

Symptôme : L’UI Web est accessible ; l’authentification échoue ou le comportement de session est étrange après un changement d’identité du nœud.
Cause racine : Mismatch de hostname, incompatibilité certificat/clé, ou identité de nœud dupliquée dans un cluster.
Correctif : Vérifiez la résolution du hostname et l’identité du nœud. Dans les clusters, assurez‑vous que les IDs de nœud sont uniques et que la config corosync est cohérente. Réémettez les certificats si nécessaire (avec prudence).

Blague #2 : L’authentification, c’est comme un lecteur de badge d’entreprise — quand ça échoue, ce n’est jamais parce que vous restez là en colère.

Listes de contrôle / plan pas-à-pas

Checklist A : Proxmox mono‑nœud, UI se charge, échec de connexion

Essayez explicitement root@pam. Ne faites pas confiance à la mémoire du menu realm.
Exécutez journalctl -u pveproxy -n 100 et cherchez la raison exacte de l’échec.
Confirmez la synchronisation horaire : timedatectl et (si présent) chronyc tracking.
Testez PAM directement : pamtester login root authenticate.
Vérifiez si root est verrouillé : passwd -S root.
Testez la création de ticket API localement avec curl (Task 15). Si curl fonctionne mais pas l’UI, suspectez navigateur/proxy.
Si vous placez Proxmox derrière un reverse proxy, contournez‑le et testez l’accès direct sur :8006.
Ce n’est qu’ensuite que vous devez envisager de redémarrer pveproxy/pvedaemon, et documentez pourquoi.

Checklist B : Proxmox en cluster, UI se charge, échec de connexion sur un nœud

Vérifiez le décalage horaire sur le nœud problématique vs un nœud sain (timedatectl sur les deux).
Vérifiez le quorum et la santé corosync : pvecm status.
Vérifiez que /etc/pve est monté : mount | grep /etc/pve.
Suivez les logs de pveproxy en tentant une connexion.
Si LDAP/AD : testez un sync de realm depuis le nœud problématique (pveum realm sync). Les problèmes de segmentation réseau touchent souvent un seul nœud.
Confirmez que le nœud n’est pas isolé par des changements de firewall (firewall Proxmox et ACL en amont).
Si le nœud est non‑quorate : ne faites pas de changements de configuration. Réparez d’abord le quorum.

Checklist C : Realms externes (LDAP/AD/OIDC) tombent soudainement

Confirmez que la connexion PAM locale fonctionne (root@pam) pour reprendre le contrôle.
Vérifiez la résolution DNS des endpoints d’identité depuis le nœud.
Vérifiez les règles firewall sortantes depuis Proxmox vers LDAP/DC/OIDC.
Cherchez des changements TLS/chaîne de confiance si vous utilisez LDAPS.
Validez que les identifiants de bind n’ont pas expiré ou été tournés sans mise à jour dans Proxmox.
Ne « corrigez » pas en créant des admins locaux aléatoires. Créez exactement un compte break‑glass approuvé et surveillez son usage.

FAQ

1) Pourquoi l’interface Web Proxmox se charge si l’authentification est cassée ?

Parce que le chargement de l’UI est surtout du contenu statique servi par pveproxy. L’authentification est un appel API séparé qui atteint les backends de realm et la logique de ticket.

2) Quelle est la différence entre `root`, `root@pam` et `root@pve` ?

root@pam est le compte root système authentifié via PAM. root@pve serait un utilisateur géré par Proxmox (si créé), distinct des comptes OS.

3) Je peux SSH en root, mais la connexion Web UI échoue. Comment ?

SSH et l’UI Web peuvent tous deux utiliser PAM, mais l’UI implique aussi la 2FA, la sélection du realm, et la gestion ticket/cookie. De plus, l’UI peut authentifier contre un realm différent de celui que vous pensez.

4) La dérive horaire peut‑elle vraiment provoquer « Échec de connexion » malgré des mots de passe corrects ?

Oui. Les tickets et le TOTP sont sensibles au temps, et même une dérive modeste peut provoquer un rejet immédiat ou un comportement de session étrange.

5) Comment savoir si c’est un problème LDAP/AD versus un problème Proxmox ?

Si root@pam fonctionne mais que user@corp-ldap échoue, c’est généralement un problème de connectivité LDAP/AD, TLS, DNS, ou d’identifiants de bind. Confirmez avec pveum realm sync corp-ldap et les logs.

6) Le fait qu’un cluster soit non‑quorate cause‑t‑il des échecs de connexion ?

Ça peut contribuer, surtout si l’état de /etc/pve n’est pas cohérent ou si pmxcfs/corosync sont instables. On voit plus souvent des opérations de config bloquées, mais l’authentification et les permissions peuvent devenir confuses pendant des partitions.

7) Dois‑je redémarrer `pveproxy` quand je vois « Échec de connexion » ?

Seulement après avoir vérifié les logs et l’heure. Redémarrer peut masquer le problème sous‑jacent (comme une dérive NTP ou une panne LDAP) et vous y reviendrez plus en colère plus tard.

8) Que faire si l’UI fonctionne en accédant directement à `https://node:8006` mais échoue derrière un reverse proxy ?

Alors le proxy est en cause. Corrigez les en‑têtes transmis (Host, X-Forwarded-Proto), la gestion WebSocket upgrade, et évitez de déformer les cookies.

9) J’ai activé la 2FA et maintenant personne ne peut se connecter. Quelle est la récupération la plus sûre ?

Utilisez votre méthode de récupération documentée (codes de récupération, compte break‑glass, accès console). Si vous n’en avez pas, créez‑en une après récupération — car ceci se reproduira.

10) Quel est le chemin « break‑glass » le plus fiable ?

Accès console (physique/IPMI) plus une voie admin locale (root@pam ou un utilisateur admin local PVE) qui ne dépend pas des fournisseurs d’identité externes.

Conclusion : étapes suivantes pour éviter une répétition

Quand Proxmox affiche « Échec de connexion » mais que l’UI se charge, vous n’avez pas affaire à un mystère. Vous avez affaire à un petit ensemble de modes de défaillance prévisibles : mismatch de realm, dérive horaire, échecs des backends d’authentification, problèmes du système de fichiers de cluster, et bizarreries proxy/navigateur liées aux tokens.

Faites ceci ensuite :

Ajoutez une entrée de runbook qui commence par : vérification du realm, journalctl -u pveproxy, vérification de la synchronisation horaire.
Mettez en place et testez un accès break‑glass : un chemin admin local qui ne dépend pas de LDAP/OIDC.
Surveillez la dérive horaire sur chaque nœud. Alertez sur la désynchronisation NTP avant que les tickets ne commencent à échouer.
Si vous utilisez un reverse proxy, traitez‑le comme du code en production. Versionnez‑le, révisez‑le, et testez les flux de connexion après chaque changement.
Dans les clusters, surveillez le quorum et la santé corosync. L’authentification et la configuration vivent dans le même écosystème d’hypothèses.

L’UI est polie. Les logs sont honnêtes. Faites confiance à celle qui est honnête.