Correction : OpenVPN n’a pas pu lire le nom d’utilisateur Auth depuis l’entrée standard

could not read Auth username from stdin ressemble à un problème d’authentification et n’en est pas un. OpenVPN a tenté de demander le nom d’utilisateur sur l’entrée standard, n’a rien trouvé de lisible et s’est arrêté avant même de contacter le serveur. Le compte peut être parfaitement valide ; le processus n’a simplement personne à qui demander.

C’est pourquoi la première étape utile consiste à confirmer ce que le client lit, et non à réessayer la connexion ni à modifier des réglages côté serveur. Parcourez les vérifications ci-dessous dans l’ordre et arrêtez-vous à la première qui échoue.

Lisez l’erreur comme une défaillance locale d’entrée

Quand auth-user-pass apparaît sans argument de fichier, le client s’attend à demander. Dans un shell interactif, cette invite fonctionne parce que le processus possède un terminal. Sous systemd, une tâche cron ou un conteneur, l’entrée standard est généralement vide, et la lecture revient aussitôt avec l’erreur que vous voyez.

Le message nomme aussi le champ qui a échoué, nom d’utilisateur ou mot de passe, ce qui indique jusqu’où la lecture est allée. Un nom d’utilisateur manquant signifie que le processus n’a rien pu lire du tout. Un mot de passe manquant après un nom d’utilisateur réussi signifie que le flux d’entrée s’est terminé entre les deux lectures, ce qui est typique d’un fichier à moitié écrit ou d’un tube fermé.

Confirmez la vision du client lui-même avant de changer quoi que ce soit d’autre. Lancez-le au premier plan avec la même configuration et le même utilisateur, et regardez si l’invite apparaît. Si elle apparaît dans votre shell mais pas sous le gestionnaire de services, la différence tient à la source d’entrée, pas aux identifiants. Une comparaison rapide du fichier d’unité et de l’environnement de votre shell montre généralement lequel fournit un terminal.

Donnez au service une source d’identifiants prise en charge

La source prise en charge pour un fonctionnement sans surveillance est un fichier d’identifiants passé en argument à auth-user-pass. Le fichier est lu comme du texte brut : la première ligne est le nom d’utilisateur, la seconde le mot de passe. Pointez-le avec un chemin absolu tel que /etc/openvpn/client/creds , afin que le répertoire de travail du compte de service ne puisse pas changer le sens de la directive.

Les permissions comptent autant que le chemin. Le fichier doit être lisible par le compte qui exécute le client et non par tout le monde, et il devrait appartenir au compte de service ou à root avec un groupe qui inclut le service. Vérifiez la lisibilité en tant que ce compte, sans imprimer le contenu.

Un chemin relatif est le mode de défaillance silencieux. Le profil peut se trouver dans un répertoire tandis que systemd démarre le processus ailleurs, si bien qu’un fichier qui se résout dans votre shell ne se résout pas pour le service. Déplacez les identifiants vers un emplacement fixe et référencez-les de façon absolue. Démarrez ensuite le service une fois et confirmez que le même chemin est utilisé, plutôt que de vous fier à la vue de l’éditeur de profils.

Si le déploiement exige un code à usage unique ou un autre défi interactif, décidez si le flux de travail du client le prend réellement en charge sans surveillance. Un fichier avec un mot de passe statique ne peut pas répondre à un code rotatif, et réessayer une invite sans réponse n’apporte aucune information.

Pourquoi script-security n’aidera pas

script-security contrôle si le client peut exécuter des scripts et combien il peut leur transmettre, y compris si un mot de passe peut être remis à un script via une variable d’environnement. Il n’a rien à dire sur l’origine du nom d’utilisateur et du mot de passe.

L’élever à un niveau supérieur est un réflexe courant parce que le message mentionne Auth, mais cela change les permissions des scripts plutôt que la source d’entrée, et cela élargit ce que le client peut exécuter. Si un script auxiliaire fait partie de la conception, corrigez d’abord la source d’entrée et gardez le niveau de sécurité à la valeur la plus basse dont le déploiement a besoin.

L’interface de gestion est une alternative légitime. Un front-end peut s’y connecter, recevoir la demande d’identifiants et répondre avec le nom d’utilisateur et le mot de passe, ce qui est le fonctionnement de certaines GUI. Si vous l’utilisez, liez-la à une adresse locale, protégez-la par un fichier de mot de passe de gestion et limitez qui peut se connecter, car c’est un canal de contrôle du client.

Vérifiez l’étape suivante après que le client a lu le fichier

Une fois que le client peut lire les identifiants, la défaillance suivante est un véritable échange avec le serveur, et son message a un sens différent. Un échec d’authentification à ce stade signifie que le serveur a rejeté le compte ; une réponse de défi signifie que le serveur veut un autre facteur. Traitez-les comme de nouveaux problèmes plutôt que comme le même répété.

Testez tout le chemin tel que le service l’exécutera : même compte, même répertoire de travail, même environnement d’unité. Une connexion qui ne fonctionne que lancée depuis votre shell est le signe qu’une variable d’environnement ou un terminal fait encore partie du flux.

Gardez ensuite les secrets là où ils doivent être. Les mots de passe dans les arguments de ligne de commande apparaissent dans la table des processus, et les mots de passe dans la sortie de débogage finissent dans les tickets. Utilisez un fichier protégé ou l’interface de gestion, gardez les journaux à un niveau qui ne répète pas les identifiants, et changez le fichier quand quelqu’un ayant accès part.

Liste de contrôle : chemin absolu des identifiants, lisible en tant que compte de service, aucun terminal requis, script-security laissé au minimum, interface de gestion seulement si elle est liée et authentifiée, et la réponse du serveur qui en résulte traitée comme un événement distinct.