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"

VPN र स्ट्याक दुवैलाई एकैचोटि डिबग गर्नु नपरोस् भनेर PAM बोल्ने उपकरणले सेवा सिधै परीक्षण गर्नुहोस्। उही सेवा नाम र खातासहितको सिधा परीक्षण सफल भयो भने समस्या खातामा होइन, डेमनले प्रमाण कसरी पठाउँछ भन्नेमा सीमित हुन्छ।

pamtester openvpn alice authenticate

कन्सोलमा काम गर्ने उही प्रमाणले सिधा परीक्षण असफल भयो भने स्ट्याकले तपाईंले अनुमान गरेको खाता स्रोत पढेको छैन। सफल भयो भने प्लगइनले चलाउने संवाद र क्लाइन्टले साँच्चै पठाएको कुरा हेर्नुहोस्। जानाजान गलत पासवर्डले पनि एकपटक चलाउनुहोस्, अस्वीकार र मोड्युल त्रुटिबीचको फरक देखिन्छ। ती दुई नतिजा VPN लगमा एउटै देखिन्छन्, यहाँ भने पूर्ण फरक।

समर्पित सेवा login सम्पादनभन्दा राम्रो

VPN का आवश्यकता अन्तरक्रियात्मक लगइनभन्दा फरक हुँदा, प्रायः फरक हुन्छन्, यसलाई आफ्नै सेवा फाइल दिनुहोस्। login वा common-auth सम्पादन गर्दा ती समावेश गर्ने हरेक प्रोग्रामको नीति बदलिन्छ, र यससँग सम्बन्ध नभएको लगइन समस्या डिबग गर्ने अर्को व्यक्तिले तपाईंको परिवर्तन पाउँछ।

आवश्यक मोड्युलहरू सानो सेवा फाइलमा कपी गर्नुहोस्, क्रम स्पष्ट राख्नुहोस्, र मालिक को हो लेख्नुहोस्। पासवर्ड रिसेटले प्रभाव नपारेको जस्तो देखिँदा जाँच्नुपर्ने त्यही फाइल हो।

क्लाइन्टले के पठाउँछ, के पठाउँदैन

क्लाइन्टले प्रयोगकर्ता नाम र पासवर्ड आफ्नो समर्थित प्रम्प्ट वा फाइलमार्फत दिन्छ। सर्भर प्लगइनले ती मानहरू PAM संवादमा पठाउँछ; यसले ती सर्भरको कन्फिगरेसनबाट पढ्दैन। पासवर्ड परिभाषित गरेजस्तो देखिने सर्भरतर्फको लाइनले त्यो गर्दैन, र कुनै पनि प्रोफाइल सम्पादनले खाता बनाउँदैन।

प्रयोगकर्ता नाम र पासवर्ड क्लाइन्ट प्रमाणपत्रसँगै रहन सक्छन्, र PAM सक्षम गर्नु प्रमाणपत्र जाँच्न छोड्ने कारण होइन। तैनाथीले चाहेका तहहरू कायम राख्नुहोस् र खाता स्रोत मात्र सुधार्नुहोस्।

स्वीकृति दुवैतर्फी हुन्छ: इच्छित खाता सफल हुन्छ, र अस्वीकार गर्नुपर्ने खाता अझै असफल हुन्छ। auth-pam प्लगइनको README ले सेवा आर्गुमेन्ट र यसले अगाडि राख्न सक्ने ब्याकएन्डहरू वर्णन गर्छ, र तपाईंले बनाउन खोजेको व्यवस्था पुष्टि गर्ने ठाउँ त्यही हो।