OpenVPN PAM: аргумент login — это служба, а не пользователь

Пользователя добавили на сервере, пароль ввели правильно, а соединение всё равно завершается с AUTH_FAILED. Обычно причину объясняет строка плагина: слово после пути к плагину — это имя службы PAM, и именно оно определяет, какой набор модулей отвечает на запрос. Это не имя пользователя и не ссылка на файл с паролями, который OpenVPN читает сам.

Что выбирает второе слово

Строка конфигурации принимает путь к плагину и один аргумент:

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

Этот аргумент передаётся библиотеке PAM как имя службы, поэтому запускается набор из /etc/pam.d/openvpn. Напишите там login, и вместо него будет действовать политика интерактивного входа со всеми модулями, которые она включает в вашем дистрибутиве.

Используйте путь к плагину из установленного пакета, а не путь, скопированный с другого хоста. Имя файла и каталог различаются между дистрибутивами, и неверный путь приводит к ошибке загрузки плагина при запуске, а не при аутентификации.

Откуда набор на самом деле берёт учётные записи

PAM — это диспетчер. Файл службы перечисляет модули по порядку, и первый, кто может ответить, решает исход. Набор с pam_unix читает локальные учётные записи; набор с модулем LDAP или RADIUS отправляет учётные данные совсем в другое место.

Прочитайте файл, в который разрешается имя службы, включая всё, что он подключает:

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

Если набор передаёт решение каталогу, добавление локальной учётной записи ничего не меняет. Если он читает локальные учётные записи, создание пользователя в каталоге тоже ничего не меняет. Учётная запись должна существовать там, где ищет набор, и именно в этом состоит весь диагноз в большинстве таких отчётов.

Одна попытка, два журнала

Проследите одно неудачное соединение по обеим сторонам. Журнал OpenVPN показывает результат работы плагина и отказ клиента; системный журнал аутентификации показывает, какой модуль запускался и что он решил. Чтение их в одном временном окне — то, что отличает отсутствующий файл службы от тайм-аута серверной части. Пробел в журнале аутентификации означает, что до набора дело не дошло вовсе.

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

Проверьте службу напрямую утилитой, которая говорит на языке PAM, чтобы не отлаживать одновременно VPN и набор. Успешная прямая проверка с тем же именем службы и той же учётной записью сводит проблему к тому, как демон передаёт учётные данные, а не к самой учётной записи.

pamtester openvpn alice authenticate

Если прямая проверка не проходит с теми же учётными данными, которые работают в консоли, набор читает не тот источник учётных записей, который вы предполагали. Если она проходит, посмотрите на диалог, который ведёт плагин, и на то, что клиент действительно отправил. Запустите её ещё раз с заведомо неверным паролем, чтобы увидеть разницу между отказом и ошибкой модуля. Эти два исхода выглядят одинаково в журнале VPN и совершенно по-разному здесь.

Отдельная служба лучше, чем правка login

Дайте VPN собственный файл службы, если её требования отличаются от интерактивного входа, а обычно они отличаются. Правка login или common-auth меняет политику для каждой программы, которая их подключает, и следующий человек, разбирающий не связанную с этим проблему входа, унаследует ваше изменение.

Скопируйте нужные модули в небольшой файл службы, сохраните явный порядок и отметьте, кто за него отвечает. Именно этот файл нужно проверять, когда сброс пароля, кажется, не даёт эффекта.

Что клиент отправляет, а что нет

Клиент передаёт имя пользователя и пароль через поддерживаемое приглашение или файл. Серверный плагин передаёт эти значения в диалог PAM; он не читает их из конфигурации сервера. Строка на стороне сервера, которая выглядит как задание пароля, этого не делает, и никакая правка профиля не создаст учётную запись.

Имя пользователя и пароль могут сосуществовать с клиентскими сертификатами, и включение PAM не повод перестать проверять сертификаты. Сохраните уровни, которые задумала эксплуатация, и исправьте только источник учётных записей.

Проверка проходит в обе стороны: нужная учётная запись входит успешно, а учётная запись, которую следует отклонить, по-прежнему получает отказ. README плагина auth-pam описывает аргумент службы и серверные части, которые он может обслуживать, и именно там стоит подтвердить схему, которую вы пытаетесь построить.