OpenVPN PAM: аргументът за вход е услуга, а не потребител

Потребител беше добавен на сървъра, паролата беше въведена правилно, а връзката все още завършва с 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 и напълно различни тук.

Отделна услуга е по-добра от редактиране на входа

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

Копирайте необходимите модули в малък файл на услуга, поддържайте реда изричен и отбележете кой го притежава. Именно този файл трябва да се провери, когато нулирането на парола изглежда без ефект.

Какво изпраща клиентът и какво не

Клиентът предоставя потребителско име и парола чрез поддържаната от него подкана или файл. Приставката на сървъра предава тези стойности в разговора PAM; тя не ги чете от конфигурацията на сървъра. Ред от страна на сървъра, който изглежда, че дефинира парола, не прави това и никакво редактиране на профил няма да създаде акаунт.

Потребителското име и паролата могат да съществуват заедно с клиентски сертификати, и включването на PAM не е причина да спрете да проверявате сертификати. Запазете слоевете, които внедряването е предвидило, и поправете само източника на акаунти.

Приемането е двустранно: предвиденият акаунт успява, а акаунт, който трябва да бъде отказан, все още се проваля. Файлът README на приставката auth-pam документира аргумента за услугата и бекендите, които може да обслужва, и там е мястото да потвърдите подредбата, която се опитвате да изградите.