PPTP affirme que votre mot de passe est faux : quelle correction vient en premier ?

Les profils PPTP qui affirment que votre mot de passe est faux vous disent quelque chose de plus étroit que cela n’en a l’air. Le secret est testé tout au bout d’une chaîne qui commence par la négociation des capacités, si bien que toute incohérence plus haut dans cette chaîne se manifeste comme un échec d’authentification. Réinitialiser le mot de passe, le retaper ou recréer le profil ne change donc rien. Lisez d’abord la négociation, puis choisissez la correction selon la part du chemin que vous contrôlez.

Pourquoi le secret n’est jamais testé

L’authentification PPP se négocie : le serveur propose des méthodes, le client répond avec ce qu’il sait faire, et les deux s’accordent sur une avant tout échange d’identifiants. Quand le serveur ne propose que EAP-PEAP et que le pppd du client ne l’implémente pas, la conversation s’arrête au stade de la proposition. Le serveur enregistre un échec d’authentification parce que c’est l’étape qui a échoué, pas parce que le mot de passe a été comparé et jugé insuffisant.

C’est pourquoi l’erreur est identique pour un mauvais mot de passe et pour une incohérence de méthode. Seul le journal les distingue, et seulement si le client est autorisé à être verbeux.

Lisez la négociation, pas la dernière erreur

Lancez la connexion au premier plan avec le débogage activé et lisez les lignes d’authentification depuis le haut. Le journal nomme la méthode proposée, la méthode acceptée et l’endroit où l’échange s’est arrêté. Un profil qui ne quitte jamais CHAP ou MSCHAPv2 alors que le serveur attend PEAP est un problème de méthode, pas un problème d’identifiants. La dernière ligne de ce journal est là où le client a abandonné, pas là où se trouve la cause.

sudo pppd call provider debug nodetach

Conservez cette sortie. C’est aussi la preuve dont le propriétaire du réseau a besoin avant de modifier la politique du serveur, et elle tranche la question de savoir si le mot de passe a seulement joué un rôle.

La seconde cause se cache dans le fichier des secrets

Si le journal montre que les méthodes concordent, regardez le fichier qui stocke le secret. Un saut de ligne ou un espace final inscrit dans le champ du mot de passe est envoyé comme partie du mot de passe, si bien que le serveur compare une chaîne différente de celle que vous avez tapée. Le fichier paraît correct dans un éditeur, et c’est précisément pourquoi il survit à tant d’essais.

sudo cat -A /etc/ppp/chap-secrets

Le signe dollar marque la fin de chaque ligne dans cette sortie. Un champ de mot de passe contenant quelque chose avant cette marque, ou un espace égaré entre les champs, doit être réécrit avec le guillemet que l’outil documente.

Choisissez la correction selon qui possède le serveur

Si le serveur est le vôtre, autoriser MSCHAPv2 pour ce compte est le plus petit changement, et vous devriez noter que vous avez accepté volontairement une méthode plus faible. S’il appartient à quelqu’un d’autre, la correction honnête est un client qui implémente EAP-PEAP ; corriger pppd fait de l’incompatibilité votre problème de maintenance. Si le choix du protocole est encore ouvert, PPTP est la partie la plus faible de la conception et la migration coûte généralement moins cher que de maintenir en vie un client corrigé. Écrivez cette décision à côté du profil pour que la personne suivante ne la rouvre pas.

Quelle que soit la voie choisie, testez ensuite depuis une seconde machine sur un autre réseau. Un profil enregistré peut continuer à proposer l’ancienne méthode et faire paraître cassé un serveur corrigé. Retirez ensuite le réglage de débogage, car des journaux PPP détaillés peuvent capturer plus que vous ne le souhaitez sur un poste partagé.