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 дакументуе аргумент службы і бэкенды, якія ён можа абслугоўваць, і менавіта там варта пацвердзіць канфігурацыю, якую вы спрабуеце пабудаваць.