OpenVPN lit le mot de passe au terminal, pas sur stdin

OpenVPN demande un nom d'utilisateur et un mot de passe sur le terminal de contrôle, et un fichier redirigé vers l'entrée standard n'est pas ce terminal. Ce seul détail explique le script qui se bloque alors que le mot de passe est là, dans le tube. L'invite est dessinée par le client et la lecture se fait sur le périphérique de terminal, donc rediriger stdin ne change rien. Alimentez le client par l'une de ses entrées documentées et le même script se connecte du premier coup.

Trois voies couvrent presque tous les cas, et chacune échoue à sa manière. Choisissez d'après l'invite que le client affiche réellement, pas d'après l'option la plus facile à scripter.

L'invite ne vient pas de stdin

Quand OpenVPN a besoin d'identifiants, il ouvre le terminal de contrôle et lit là. C'est pourquoi un test interactif semble correct alors que la même commande sous cron ou dans un fichier d'unité reste immobile, l'invite écrite dans un journal que personne ne regarde. Certaines compilations retombent sur l'entrée standard quand aucun terminal n'existe, et cette incohérence est pire qu'un échec net parce qu'elle cache le problème jusqu'au déploiement.

Vérifiez l'environnement avant d'écrire la moindre ligne de code : lancez le client sous le même utilisateur, avec le même stdin, que ce que fera le planificateur ou le gestionnaire de services. Si l'invite n'apparaît jamais dans le journal et que le processus ne progresse pas, quelque chose attend un terminal qui n'existe pas.

Première voie : un fichier d'identifiants de deux lignes

L'option d'authentification prend un chemin, et le fichier contient exactement deux lignes, le nom d'utilisateur puis le mot de passe, sans rien d'autre. Passez le chemin explicitement au lieu de compter sur un nom de fichier par défaut, car un fichier d'identifiants égaré dans le répertoire de travail est la façon dont le mauvais compte finit par servir. Réglez le mode sur 0600 et donnez la propriété au compte qui exécute le client.

Le client lit ce fichier une fois au démarrage, donc faire tourner le mot de passe signifie redémarrer le processus. C'est généralement le comportement souhaité, et cela appartient au runbook à côté de la procédure de rotation.

Deuxième voie : askpass pour la phrase de la clé

Une clé privée protégée par une phrase déclenche une seconde invite, différente, et elle a sa propre réponse par fichier : l'option askpass lit la phrase sur la première ligne d'un fichier. Pour les tunnels fondés sur SSH, l'équivalent est un programme askpass que le client exécute, et dont la sortie standard devient le secret.

Aucune des deux formes ne met le secret dans la liste des arguments, et toutes deux le laissent exister comme fichier ou comme exécutable qui l'affiche. La protection, ce sont les permissions de fichier et la propriété du processus, pas l'obscurité. Un assistant qui réémet une chaîne codée en dur est un secret avec des étapes en plus.

Troisième voie : la CLI propre au client du portail

Les clients d'entreprise fournissent généralement un point d'entrée en ligne de commande qui se connecte à un portail nommé sans aucune fenêtre, et c'est la voie prise en charge. Sous Linux, le client GlobalProtect expose les opérations de connexion et d'import de certificat via sa CLI, et les portails qui utilisent l'authentification par certificat ont besoin de l'étape d'import avant qu'une connexion automatisée puisse fonctionner. Préférez-la aux frappes synthétisées : vous obtenez un vrai code de sortie, aucune dépendance au focus de la fenêtre, et elle survit à un écran verrouillé.

Si la première connexion exige encore qu'un humain accepte un certificat, l'automatisation n'est pas terminée. Faites l'import pendant l'installation et consignez-le comme prérequis.

Quand le flux a besoin d'un pseudo-terminal

Une séquence qui demande un mot de passe puis un code à usage unique n'a pas de fichier unique à lire. Un pilote de terminal comme Expect est le bon outil parce qu'il attend chaque motif tour à tour, et il lui faut le processus lancé avant de pouvoir faire correspondre quoi que ce soit.

Deux échecs dominent. Un script qui attend une invite sans lancer le client attend indéfiniment, et Tcl n'est pas un shell, donc l'arithmétique de shell écrite dans un bloc expect ne s'évalue pas comme elle se lit. Gardez le drapeau de débogage actif pendant que vous construisez les motifs, puis coupez-le.

Des secrets qui fuient, et où ils se cachent

Tout ce qui passe en argument est visible dans la liste des processus, donc les identifiants appartiennent à un fichier ou à un assistant, jamais à la ligne de commande. Les codes à usage unique sont consommés par conception et doivent être produits à chaque tentative. Les journaux d'échec portent souvent le nom d'utilisateur et parfois davantage, alors expurgez-les avant de les envoyer n'importe où, et gardez le secret hors du profil lui-même, car un fichier de configuration avec un mot de passe intégré finit collé dans des tickets et des dépôts. Faire tourner le compte signifie alors traquer chaque copie, et c'est exactement le coût que cette disposition évite.

Auditez les voies que vous avez choisies, puis câblez-les dans le fichier d'unité ou le planificateur qui exécutera réellement le client. Le tunnel vit exactement aussi longtemps que ce processus.