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 का रूपमा सफल हुने आदेशले फाइल अवस्थित छ भन्ने मात्र बताउँछ। वास्तविक सेवाबाट लगइनले मोड्युलले रहस्य पढ्न, प्रयोग गर्न र आवश्यक कुरा फर्काएर लेख्न सक्छ कि भनी बताउँछ।

अन्तमा, आवश्यकता अक्षत राख्नुहोस्। शून्य-पासवर्ड विकल्प थप्ने, पढ्न-मात्र असफलता स्वीकार्ने वा स्यान्डबक्स हटाउने — यी सबै नीति बदलेर लक्षण हटाउँछन्। कोड प्रस्तुत गर्नुपर्ने प्रयोगकर्तालाई रहस्य अप्राप्य हुँदा पनि अस्वीकार गर्नुपर्छ।