OpenVPN PAM : l’argument de connexion est un service, pas un utilisateur

Un utilisateur a été ajouté sur le serveur, le mot de passe a été saisi correctement, et la connexion se termine quand même par AUTH_FAILED. La ligne du greffon explique souvent pourquoi : le mot qui suit le chemin du greffon est un nom de service PAM, et il détermine quelle pile de modules répond à la question. Ce n’est pas un nom d’utilisateur, et ce n’est pas un pointeur vers un fichier de mots de passe que OpenVPN lirait lui-même.

Ce que sélectionne le second mot

La ligne de configuration prend un chemin de greffon et un argument :

plugin /usr/lib/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn

Cet argument est transmis à la bibliothèque PAM comme nom de service, ce qui fait s’exécuter la pile située dans /etc/pam.d/openvpn. Écrivez-y login et vous obtenez à la place la politique de connexion interactive, avec les modules que cette politique inclut sur votre distribution.

Utilisez le chemin du greffon fourni par le paquet installé, pas un chemin copié depuis un autre hôte. Le nom de fichier et le répertoire diffèrent d’une distribution à l’autre, et un mauvais chemin échoue au démarrage avec une erreur de chargement du greffon, pas à l’authentification.

Où la pile lit réellement les comptes

PAM est un répartiteur. Le fichier de service liste les modules dans l’ordre, et le premier qui peut répondre décide du résultat. Une pile qui appelle pam_unix lit les comptes locaux ; une pile qui appelle un module LDAP ou RADIUS envoie les identifiants ailleurs.

Lisez le fichier vers lequel le nom de service se résout, y compris tout ce qu’il inclut :

cat /etc/pam.d/openvpn
grep -H pam_ /etc/pam.d/openvpn /etc/pam.d/common-auth

Si la pile délègue à un annuaire, ajouter un compte local ne change rien. Si elle lit les comptes locaux, créer l’utilisateur dans l’annuaire ne change rien non plus. Le compte doit exister là où la pile regarde, et c’est tout le diagnostic dans la plupart de ces rapports.

Une tentative, deux journaux

Corrélez une seule connexion en échec des deux côtés. Le journal OpenVPN montre le résultat du greffon et le rejet du client ; le journal d’authentification du système montre quel module a été exécuté et ce qu’il a décidé. Les lire dans la même fenêtre temporelle est ce qui distingue un fichier de service manquant d’un délai d’attente du backend. Un trou dans le journal d’authentification signifie que la pile n’a jamais été atteinte.

journalctl -u openvpn-server@server --since "-2 min"
journalctl -t sshd -t sudo --since "-2 min"

Testez le service directement avec un utilitaire qui parle PAM, pour ne pas déboguer le VPN et la pile en même temps. Un test direct réussi avec le même nom de service et le même compte réduit le problème à la façon dont le démon transmet les identifiants, pas au compte lui-même.

pamtester openvpn alice authenticate

Si le test direct échoue avec les mêmes identifiants qui fonctionnent en console, la pile ne lit pas la source de comptes que vous supposiez. S’il réussit, regardez la conversation que mène le greffon et ce que le client a réellement envoyé. Lancez-le aussi une fois avec un mot de passe volontairement faux, pour voir la différence entre un refus et une erreur de module. Ces deux issues paraissent identiques dans le journal du VPN et totalement différentes ici.

Un service dédié vaut mieux que modifier la connexion

Donnez au VPN son propre fichier de service quand ses exigences diffèrent de la connexion interactive, ce qui est généralement le cas. Modifier login ou common-auth change la politique de tous les programmes qui les incluent, et la personne suivante qui débogue un problème de connexion sans rapport hérite de votre modification.

Copiez les modules nécessaires dans un petit fichier de service, gardez l’ordre explicite, et notez à qui il appartient. C’est ce fichier qu’il faut vérifier quand une réinitialisation de mot de passe semble sans effet.

Ce que le client envoie, et ce qu’il n’envoie pas

Le client fournit un nom d’utilisateur et un mot de passe via son invite ou son fichier pris en charge. Le greffon du serveur transmet ces valeurs à la conversation PAM ; il ne les lit pas dans la configuration du serveur. Une ligne côté serveur qui semble définir un mot de passe ne le fait pas, et aucune modification de profil ne créera de compte.

Un nom d’utilisateur et un mot de passe peuvent coexister avec des certificats clients, et activer PAM n’est pas une raison d’arrêter de vérifier les certificats. Conservez les couches prévues par le déploiement et ne corrigez que la source des comptes.

L’acceptation est bidirectionnelle : le compte prévu réussit, et un compte qui devrait être refusé échoue toujours. Le README du greffon auth-pam documente l’argument de service et les backends qu’il peut présenter, et c’est l’endroit pour confirmer la disposition que vous cherchez à construire.