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 म्हणून यशस्वी होणारा आदेश फाइल अस्तित्वात आहे एवढेच सांगतो। खऱ्या सेवेद्वारे लॉगिन मॉड्यूल रहस्य वाचू, वापरू आणि आवश्यक ते परत लिहू शकते का हे सांगते।

शेवटी, आवश्यकता अक्षत ठेवा। शून्य-पासवर्ड पर्याय जोडणे, फक्त-वाचन अयशस्वी स्वीकारणे किंवा सँडबॉक्स काढणे — हे सर्व धोरण बदलून लक्षण नाहीसे करतील। ज्याला कोड सादर करावा लागतो त्या वापरकर्त्याला रहस्य अप्राप्य असतानाही नकार दिला पाहिजे।