Le --key-password d’OpenConnect est-il le mot de passe de votre compte VPN ?

Lisez le nom de l’option au pied de la lettre. Il désigne une clé, et la confusion commence quand le fichier déverrouillé est pris pour le compte authentifié. Collez le mot de passe du compte dans cette option et le client tentera d’ouvrir un fichier de clé avec lui, ce qui échoue pour des raisons sans aucun rapport avec la connexion VPN.

La partie déroutante est qu’une seule connexion peut légitimement avoir besoin des deux secrets. L’authentification par certificat client peut exiger une clé chiffrée, et la même passerelle peut encore mener un échange d’authentification utilisateur après l’acceptation du certificat. Aucun des deux secrets ne satisfait l’autre étape, et une défaillance de l’un ressemble beaucoup, vue de l’extérieur, à une défaillance de l’autre.

Deux secrets, deux métiers différents

Lisez les rôles comme un accès au fichier face à une admission sur le réseau. Le mot de passe de la clé déchiffre la clé privée PEM indiquée par --sslkey afin que le certificat client TLS puisse être présenté. Ce déchiffrement se fait localement, à l’intérieur du processus client, et la phrase secrète elle-même ne voyage jamais vers la passerelle. Ce que la passerelle voit, c’est le certificat et une signature faite avec la clé. Le manuel d’OpenConnect garde --key-password à côté de --certificate et --sslkey, et sur les versions capables d’utiliser une clé conservée dans un TPM la même option porte à la place le mot de passe de la clé racine de stockage.

Le mot de passe du compte est d’une autre nature. Il entre dans l’échange d’authentification : un formulaire identifiant et mot de passe, un jeton, un aller-retour SAML ou une combinaison annoncée par la passerelle. Certains déploiements ne le demandent pas du tout quand le certificat est le seul facteur, et d’autres le demandent même après un certificat, parce que le certificat prouve l’appareil tandis que le compte prouve la personne.

Mélanger les deux produit des erreurs trompeuses. Une passerelle qui refuse une connexion signale généralement un échec d’authentification, alors qu’une phrase secrète de clé incorrecte échoue plutôt plus tôt, quand la couche TLS ne peut pas lire le fichier de clé. Ce sont des étapes différentes avec des correctifs différents, et les noms se ressemblent assez pour que les gens les inversent puis courent après le mauvais journal. Notez quelle invite est apparue avant de changer le moindre réglage, car le libellé de l’invite est le diagnostic le moins cher dont vous disposez.

Quand le mot de passe de la clé est réellement nécessaire

L’option n’a de sens que lorsqu’il y a une clé chiffrée à déverrouiller. Si vous vous connectez avec un identifiant et un mot de passe et sans certificat client, --key-password n’a rien sur quoi agir, et l’inclure ne change rien. Si vous vous connectez avec --certificate et --sslkey, le format propre au fichier de clé décide si une phrase secrète est demandée ou non.

Les deux secrets dans une seule commande sont courants en environnement géré : un certificat d’appareil dans une clé chiffrée, plus une connexion par utilisateur. La bonne séquence est de laisser le client demander la phrase secrète de la clé localement, de terminer la poignée de main du certificat, puis de traiter séparément l’invite de compte de la passerelle. Vouloir préremplir les deux via un unique script réutilisé est là où la confusion commence généralement.

Un diagnostic utile consiste à regarder quand la défaillance se produit. Si le client s’arrête avant le début de toute authentification réseau, soupçonnez le fichier de clé, son format ou la phrase secrète. Si la session TLS est établie et que la passerelle rejette ensuite l’utilisateur, la clé a fait son travail et le problème vient de l’échange de compte.

Garder les deux secrets hors de l’historique du shell

Les arguments de ligne de commande sont lisibles par les autres utilisateurs locaux via la table des processus et sont souvent capturés dans l’historique du shell, les scripts et les transcriptions de support. OpenConnect peut lire le mot de passe du compte depuis l’entrée standard avec --passwd-on-stdin, et la phrase secrète de la clé peut venir d’une invite interactive ou d’un agent plutôt que d’un argument. Aucun mécanisme ne rend le secret sûr à lui seul, mais les deux le gardent hors des endroits les plus exposés.

Les fichiers méritent le même soin. Un script qui écrit une phrase secrète dans un fichier temporaire devrait le créer avec des permissions restrictives, le supprimer en sortie et éviter les répertoires lisibles par tous. Une phrase secrète qui survit à la session dans un répertoire temporaire est une copie que vous avez oublié de faire. Les variables d’environnement sont visibles des processus enfants et finissent souvent recopiées par les outils de débogage, elles ne sont donc pas une amélioration gratuite par rapport aux arguments.

La sortie de diagnostic est la fuite silencieuse. Les journaux du client à verbosité élevée peuvent montrer des corps de requête ou des valeurs d’option, et une transcription de terminal copiée se colle facilement dans un ticket, alors lisez la sortie avant de la partager.

Un bouton de bureau mort est une autre panne

Une entrée VPN de bureau qui affiche un indicateur d’attente puis plus rien n’est généralement pas du tout un problème d’authentification. Le bouton appartient à un gestionnaire de réseau, à une applet d’éditeur ou à un greffon qui lance OpenConnect à votre place, et un composant manquant ou un profil illisible peuvent produire exactement ce symptôme. Trouvez quel processus le bouton démarre et lisez son erreur avant de toucher aux identifiants.

Il est tentant d’assouplir la vérification du certificat ou de désactiver un contrôle quand l’interface graphique refuse de se connecter. Cela transforme une panne d’intégration du client en régression de sécurité et corrige rarement le problème de lancement. Gardez la vérification du serveur intacte, confirmez que le profil pointe vers la passerelle prévue et vérifiez que l’assistant attendu par l’interface est réellement installé.

Une courte liste sépare les cas. Une défaillance locale avant qu’un paquet ne parte désigne la clé ou l’installation du client. Un rejet de la passerelle après la session TLS désigne l’échange de compte. Un bouton qui ne lance jamais le client désigne l’intégration de bureau. Trois pannes différentes, dont l’une est un mot de passe que vous étiez sur le point de coller dans la mauvaise case.