ProtectHome बनाम TOTP सीड: VPN लॉगिन क्यों विफल होता है

प्रमाणक एक नया छह अंकों का कोड दिखाता है, VPN उसे अस्वीकार करता है, और वही कोड आपके अपने शेल से परीक्षण करने पर ठीक सत्यापित होता है। यही अंतर पूरी कहानी है। जो PAM मॉड्यूल नामांकन रहस्य खोल नहीं सकता, वह गलत कोड जैसी ही दिखने वाली विफलता लौटाता है, और होम निर्देशिकाओं को छिपाने वाला सेवा वातावरण इसका आम कारण है। किसी भी अनुमति में ढील देने से पहले तय करें कि आप तीन स्थितियों में से किसमें हैं।

यह तीन विफलताओं में से कौन-सी है?

पहला वह रहस्य है जिसे मॉड्यूल बिल्कुल पढ़ नहीं सकता। दूसरा वह रहस्य है जिसे वह पढ़ सकता है पर अपडेट नहीं कर सकता। तीसरा वह कोड है जो वास्तव में गलत है, आमतौर पर घड़ी के बहाव या दोबारा चलाए गए मान के कारण।

एक असफल प्रयास के लिए सेवा जर्नल और सिस्टम प्रमाणीकरण लॉग पढ़कर उन्हें अलग करें, फिर पुष्टि करें कि प्लगइन कौन-सी PAM सेवा लोड करता है और वह सेवा कौन-सी मॉड्यूल पंक्ति उपयोग करती है। सामान्य प्रमाणीकरण विफलता संदेश उन्हें अलग नहीं करता, और सफल मैनुअल परीक्षण भी नहीं, क्योंकि आपका शेल सेवा का वातावरण नहीं है।

जब केवल सेवा विफल होती है तो यूनिट का फ़ाइलसिस्टम दृश्य ही आम दोषी होता है।

systemctl show -p ProtectHome -p ProtectSystem -p ReadWritePaths [email protected]
ls -l /var/lib/vpn-otp/*/.google_authenticator 2>/dev/null | head -n 20

विकल्प A: रहस्य को होम से बाहर ले जाएँ

जब सेवा /home छिपाती है और आप वह सुरक्षा रखना पसंद करते हैं, तो रहस्य को कहीं ऐसी जगह रखें जहाँ वह उसे देख सके। मॉड्यूल secret= पथ और फ़ाइल संचालन करने वाला user= खाता स्वीकार करता है, जिससे केंद्रीय भंडार कई पहचानों की सेवा कर सकता है।

यह साफ-सुथरा विकल्प है, और इसी में सबसे अधिक सावधानी चाहिए, क्योंकि साझा भंडार एक ही निर्देशिका को हर खाते की सुरक्षा सीमा बना देता है।

auth required pam_google_authenticator.so secret=/var/lib/vpn-otp/${USER}/.google_authenticator user=vpn-otp

इस पर भरोसा करने से पहले तीन बातें जाँचें: खाता मौजूद है, मॉड्यूल की कार्य प्रक्रिया उसमें बदल सकती है, और फ़ाइलें प्रतिबंधक मोड के साथ उसकी हैं। user= के साथ ~ या होम-चर पथ का उपयोग न करें, और पथ को काम कराने के लिए मॉड्यूल की स्वामित्व जाँच बंद न करें। पासवर्ड चरण और बाकी स्टैक को अक्षुण्ण रखें।

विकल्प B: फ़ाइल रहने दें और पथ खोलें

अगर रहस्य उपयोगकर्ता के होम में ही रहना चाहिए, तो यूनिट को ऐसा दृश्य चाहिए जो होस्ट पर हर होम उजागर किए बिना उस एक निर्देशिका को शामिल करे। एक drop-in सैंडबॉक्स किए गए होम के नीचे संकीर्ण रूप से सीमित बाइंड माउंट जोड़ सकता है।

यह प्रति-उपयोगकर्ता स्वामित्व को मॉडल के रूप में रखता है, पर यूनिट परिवर्तन की कीमत पर जिसकी समीक्षा हर बार सैंडबॉक्स बदलने पर करनी होती है।

दो सीमाएँ आसानी से छूट जाती हैं। सैंडबॉक्स जिस निर्देशिका को छिपाता है उसके नीचे जोड़ा गया केवल-पढ़ने योग्य पथ उसे उजागर नहीं करता, क्योंकि मूल निर्देशिका वहाँ ही नहीं है। और अगर मॉड्यूल को स्थिति अपडेट करनी है तो माउंट लिखने योग्य होना चाहिए, जो अगला विकल्प सामने लाता है। drop-in को अलग फ़ाइल के रूप में लिखें, /usr/lib के नीचे पैकेज किए गए यूनिट को संपादित करने के बजाय, ताकि पैकेज अपग्रेड उसे चुपचाप रद्द न कर दे।

विकल्प C: सैंडबॉक्स रखें और स्थिति लेखन ठीक करें

रहस्य पढ़ना प्रमाणीकरण का केवल आधा है। मॉड्यूल समय-बहाव जानकारी, पुनरावृत्ति सुरक्षा या काउंटर फिर से लिख सकता है, और पढ़ने की जाँच पास करने वाली फ़ाइल फिर भी लिखने में विफल हो सकती है।

वह विफलता इस प्रयास में नहीं बल्कि अगले प्रयास में खराब कोड जैसी दिखती है, इसलिए इसे घड़ी के बहाव से भ्रमित किया जाता है।

पूरे होम को लिखने योग्य बनाने के बजाय उसे अपनी लिखने योग्य निर्देशिका दें और रहस्य का पथ वहाँ निर्देशित करें। निर्देशिका का स्वामी, फ़ाइलसिस्टम की खाली जगह और यह कि यूनिट कहीं और लेखन सीमित करती है या नहीं, की पुष्टि करें। फिर लगातार दो लॉगिन जाँचें, क्योंकि दूसरा लेखन पथ सिद्ध करता है और पहला केवल पढ़ना।

स्वयं के रूप में नहीं, सेवा के रूप में सत्यापित करें

हर महत्वपूर्ण जाँच यूनिट की सैंडबॉक्स के भीतर यूनिट की पहचान के साथ चलनी चाहिए।

root के रूप में सफल होने वाला आदेश आपको बताता है कि फ़ाइल मौजूद है और कुछ नहीं। वास्तविक सेवा के माध्यम से लॉगिन बताता है कि मॉड्यूल रहस्य पढ़, उपयोग कर और जो चाहिए वह वापस लिख सकता है या नहीं।

अंत में, आवश्यकता को अक्षुण्ण रखें। शून्य-पासवर्ड विकल्प जोड़ना, केवल-पढ़ने की विफलताएँ स्वीकार करना या सैंडबॉक्स हटाना—ये सभी नीति बदलकर लक्षण गायब कर देते। जिसे कोड प्रस्तुत करना होता है, उसे रहस्य अप्राप्य होने पर अस्वीकार किया जाना चाहिए।