Le service OpenVPN se bloque sur la demande de mot de passe de la clé privée : comment corriger

OpenVPN demande la phrase secrète de la clé privée sur la machine locale, donc un fichier de connexion valide n’y répond jamais. Dans un service, il n’y a pas de terminal où saisir, et le démarrage soit se bloque, soit échoue avec une entrée de journal qui nomme l’entrée plutôt que la cause. Deux secrets sont en jeu, et chacun a besoin de sa propre source lisible avant le redémarrage de l’unité. La démarche ci-dessous les sépare, puis vérifie l’identité qui ouvre réellement chaque fichier.

Distinguer les deux demandes

La phrase secrète de la clé déchiffre la clé privée locale ; les identifiants du compte authentifient la session auprès du serveur. Ils viennent d’endroits différents, échouent à des moments différents et produisent des messages différents. Les confondre envoie chercher une réinitialisation de mot de passe alors que le compte n’était pas en cause. Lisez le texte de la demande avant de modifier une option, car la formulation est le seul indice fiable sur le secret manquant.

Dans Community OpenVPN 2.x, askpass désigne un fichier qui contient la phrase secrète de la clé sur sa première ligne, et auth-user-pass un fichier avec le nom d’utilisateur sur une ligne et le mot de passe sur la suivante. Aucun des deux fichiers ne peut satisfaire l’autre option. Une application de bureau ou un profil NetworkManager peut garder les deux dans son propre magasin de secrets, qu’un client en ligne de commande ne lit jamais, donc notez quel client vous configurez avant d’écrire un chemin.

Pointer les deux options vers des fichiers lisibles

Un profil qui a besoin des deux entrées finit avec trois références de fichier : la clé chiffrée, la phrase secrète qui la déverrouille et la paire de connexion. Ajoutez-les sans toucher à la CA ni aux contrôles d’identité, car ceux-ci décident qui est le serveur et ne font pas partie de ce problème. Si le déploiement n’utilise pas du tout d’identifiants de compte, ajouter auth-user-pass crée une entrée que personne ne peut fournir.

key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.auth

Les options sans argument se comportent différemment des options avec chemin, et la différence compte sur un service. Un askpass sans argument lit encore la console, et un fichier auth-user-pass ne contenant qu’un nom d’utilisateur laisse encore une demande de mot de passe en attente. Une fois le client passé en démon, il ne peut plus du tout demander de saisie à un terminal, donc un service configuré ainsi ne démarre pas.

Les chemins absolus suppriment la question du répertoire de travail mais n’accordent pas l’accès. La propriété, le mode et la traversée viennent ensuite, et les trois sont vérifiés par rapport au compte sous lequel le processus s’exécute.

Lire la configuration de l’unité avant le profil

C’est l’unité, et non le fichier que vous éditiez, qui décide quelle configuration l’instance charge. Lisez sa ligne de commande et tout drop-in, puis suivez le répertoire de travail jusqu’au profil réellement utilisé. Une référence de phrase secrète ajoutée à un autre fichier .ovpn ne change rien pour cette instance.

Trois commandes en lecture seule répondent à l’essentiel. La première affiche l’unité et les éventuels drop-in, la deuxième l’identité et les réglages de sandbox qui encadrent le processus, et la troisième ce dont le dernier démarrage s’est réellement plaint. Utilisez le nom d’instance qui existe sur l’hôte :

systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -b

Faites attention à ProtectHome et aux options propres au profil user, group et chroot. Un fichier sous un répertoire personnel peut être lisible dans votre shell et invisible dans le service une fois les répertoires personnels masqués. Le compte avec lequel systemd démarre n’est pas toujours celui qui finit par ouvrir la clé.

Prouver que l’identité d’exécution peut ouvrir les deux fichiers

Lire le mode ne suffit pas, car chaque répertoire du chemin doit être traversable par la même identité. Parcourez le chemin composant par composant, puis testez l’ouverture avec le compte que le processus utilise. Un fichier en mode 600 appartenant à root ne fonctionne que tant que le processus est encore root, ce qui n’est pas vrai après l’abaissement de privilèges que font beaucoup de profils. Deux commandes couvrent la traversée et l’ouverture :

namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readable

La première affiche le mode de chaque composant et échoue là où le compte ne peut pas traverser ; la seconde répond à la seule question qui compte : l’identité d’exécution peut-elle ouvrir le fichier en lecture. Aucune n’affiche le contenu du fichier, ce qui est justement le but quand le fichier contient une phrase secrète. Répétez le test pour le fichier de connexion, car les deux sont souvent stockés avec des propriétaires différents.

Si le processus utilise un chroot ou un namespace restreint, exécutez le même test depuis cette vue, sinon la réponse décrit le mauvais système de fichiers. Une phrase secrète stockée sous un répertoire personnel masqué est l’exemple habituel d’un test qui passe hors de l’unité et échoue dedans.

Vérifier le premier démarrage, puis une reconnexion

Démarrez l’instance une fois et lisez la première défaillance plutôt que la dernière. Un fichier d’entrée manquant, un déchiffrement de clé échoué et un AUTH_FAILED côté serveur sont trois événements différents avec trois réparations différentes. Corriger un avertissement de permissions ne prouve rien sur le fait que la clé a été déverrouillée.

La ligne du journal indique lequel des trois vous avez. La réparation découle de l’entrée qui a échoué :

Testez ensuite le cycle de vie dont vous avez réellement besoin : un démarrage au boot et toute reconnexion prise en charge, pas seulement un démarrage manuel depuis votre shell. Avec auth-nocache, les entrées sont abandonnées après la première utilisation, donc une reconnexion ultérieure a toujours besoin d’une source lisible. Un trousseau déverrouillé à la connexion du bureau n’est pas disponible pour un service démarré avant que quiconque se connecte, et c’est la raison habituelle pour laquelle un test manuel passe et un redémarrage échoue. Si le premier démarrage réussit et qu’une reconnexion ultérieure échoue, lisez le journal pour l’événement de reconnexion avant de changer à nouveau les permissions.

Stocker la phrase secrète à côté de la clé réduit ce que le chiffrement vous apporte, donc restreignez ce fichier et ses sauvegardes. Traitez la suppression de la phrase secrète de la clé comme une décision d’identifiants distincte, et non comme la réparation d’une entrée manquante. Un déploiement qui dépend d’une approbation humaine ou d’une MFA interactive a besoin de son agent ou de son intégration de gestion prise en charge ; un code à usage unique enregistré en permanence n’est pas un remplacement équivalent.