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 સક્ષમ કરવું પ્રમાણપત્રોની ચકાસણી બંધ કરવાનું કારણ નથી. જમાવટે ધારેલા સ્તરો રાખો અને ફક્ત ખાતાનો સ્રોત સુધારો.

સ્વીકૃતિ દ્વિપક્ષીય છે: ઇચ્છિત ખાતું સફળ થાય છે, અને નકારવા યોગ્ય ખાતું હજી પણ નિષ્ફળ જાય છે. ફાઇલ auth-pam પ્લગઇનનું README સેવા દલીલ અને જે બેકએન્ડ તે સંભાળી શકે તેનું દસ્તાવેજીકરણ કરે છે, અને તમે જે ગોઠવણ બનાવવા પ્રયત્ન કરો છો તેની પુષ્ટિ કરવાની જગ્યા ત્યાં જ છે.