Invite TOTP d’OpenConnect absente dans NetworkManager : quatre vérifications

La passerelle accepte le mot de passe, demande un code, et la boîte de dialogue n’offre aucun champ pour cela. Rien n’a été mal saisi : le greffon NetworkManager a terminé l’échange de secret sans demander la valeur à six chiffres. Parcourez les quatre vérifications ci-dessous dans l’ordre, car une seule d’entre elles modifie le client. Le reste de la liste écarte la passerelle, le compte et la compilation du greffon.

Première vérification : lisez où l’authentification s’est arrêtée

Un mot de passe erroné échoue immédiatement. Un second facteur manquant échoue après l’étape des identifiants, généralement avec une invite répétée ou un délai expiré côté passerelle. Le moment et le journal de la passerelle indiquent quel tour est resté sans réponse.

Lisez le journal de connexion avant de toucher au profil. Si la passerelle signale une authentification incomplète ou un défi expiré, le client n’a jamais envoyé le code. Si elle signale des identifiants invalides, le problème est le mot de passe et aucun réglage TOTP ne le corrigera.

Notez l’ordre exact des invites attendu par la passerelle : nom d’utilisateur, mot de passe, puis code, ou nom d’utilisateur, code, puis mot de passe. Certaines passerelles réordonnent les tours, et un client qui ne connaît que le premier ordre bloquera au second.

Deuxième vérification : utilisez le client qui possède le défi

OpenConnect lui-même implémente toute la conversation, y compris le tour de défi. L’exécuter directement est le moyen le plus prévisible de confirmer que le compte et la passerelle fonctionnent :

sudo openconnect --protocol=anyconnect --useragent=AnyConnect vpn.example.net

Le client demande dans l’ordre où la passerelle demande. L’agent utilisateur compte parce que certaines passerelles adaptent le flux de connexion à un client connu, et une chaîne générique peut produire un flux plus court qui ne demande jamais le code. Exécutez-le une fois au premier plan avant de mettre en place un quelconque service en arrière-plan.

Si la ligne de commande demande correctement, le compte, la passerelle et le second facteur sont bons. Le problème restant est la boîte de dialogue du greffon, pas le service d’authentification. Cela isole le composant défaillant sans toucher au serveur. Conservez la sortie de la commande avec le compte rendu d’incident.

Si la ligne de commande saute aussi l’invite, arrêtez-vous et vérifiez la configuration de la passerelle avec son responsable. Aucun client de bureau ne peut répondre à un défi que le serveur n’envoie jamais.

Troisième vérification : voyez si votre greffon expose le mode TOTP

Certaines compilations de NetworkManager OpenConnect exposent un mode jeton et un champ d’agent utilisateur dans l’onglet Identity de la connexion. Réglez l’agent utilisateur sur la valeur attendue par la passerelle, sélectionnez la saisie manuelle de TOTP et enregistrez la connexion.

L’existence de ces champs dépend de la version du greffon et de l’éditeur de connexions utilisé par le bureau. Un éditeur autonome peut afficher des options que le panneau GNOME masque, ou l’inverse. Vérifiez la version du paquet installé avant de chercher un réglage caché.

Si le mode jeton est présent et que l’invite n’apparaît toujours pas, la compilation n’a pas la transmission du défi entre le greffon et la boîte de dialogue générique des secrets. Ressaisir le mot de passe, réinstaller le même paquet ou vider le trousseau ne créera pas un champ que la compilation n’implémente pas.

Quatrième vérification : traitez un code généré comme un compromis

Un script peut appeler oathtool pour le code courant et transmettre le nom d’utilisateur, le mot de passe et le code à nmcli connection up --ask. La séquence fonctionne, mais le secret partagé finit stocké à un endroit lisible par quiconque peut ouvrir le script, et ce lecteur peut fabriquer des codes pour toujours. C’est une extension permanente de la surface d’identifiants, pas une correction du client.

Qui le choisit doit verrouiller le fichier de secret sur root, garder les valeurs générées hors de l’historique du shell et traiter le script comme du matériel d’identifiants. Un habillage qui renvoie le code au terminal jette le second facteur. Testez d’abord l’habillage avec un compte jetable.

Le script doit aussi suivre l’ordre des invites de la passerelle. Si le serveur demande le code avant le mot de passe, une séquence d’entrée fixe envoie la mauvaise valeur à la mauvaise invite et produit la même authentification incomplète. Entraînez-vous avec un compte de test avant de le brancher sur une tâche de connexion.

Confirmez la même passerelle et le même compte

Testez chaque contournement contre la même passerelle, le même compte et le même groupe de tunnel. Une passerelle qui exige aussi un certificat d’appareil peut rejeter le client en ligne de commande pour une raison sans rapport avec TOTP, et l’ordre des invites peut différer de celui que vous avez répété.

Notez le client, sa version, l’agent utilisateur et l’ordre des invites qui a fonctionné. Ce compte rendu dit à la personne suivante si le problème vient de la compilation du greffon, du flux de la passerelle ou de la politique du compte, sans un nouveau tour de réinitialisations de mot de passe.

Terminez en vous reconnectant une fois après une déconnexion complète. Un secret en cache peut faire paraître un flux cassé réparé jusqu’à la session suivante, et c’est à la seconde connexion que l’invite manquante revient généralement.