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 го опишува аргументот за службата и задните делови што може да ги опслужи, и токму таму треба да се потврди поставеноста што ја градите.