auth-nocache और क्रेडेंशियल फ़ाइल: मदद करता है या नुकसान?
auth-nocache माँगे गए क्रेडेंशियल को मेमोरी से हटा देता है। जब पासवर्ड किसी फ़ाइल में हो, चेतावनी का अर्थ कम हो जाता है, और विकल्प फिर से बातचीत तोड़ सकता है।
OpenVPN शुरू होते समय एक चेतावनी छापता है जो सुझाव देती है auth-nocache, और लुभावना जवाब है विकल्प जोड़ना और पंक्ति को गायब होते देखना। वह सलाह इंटरैक्टिव लॉगिन मान लेती है। जैसे ही उपयोगकर्ता नाम और पासवर्ड किसी फ़ाइल में रहने लगते हैं, तुलना बदल जाती है: विकल्प टिकाऊ प्रति की रक्षा करना बंद कर देता है, और विशेषाधिकार छोड़ने वाले क्लाइंट पर यह बाद में फिर से बातचीत तोड़ सकता है। प्रोफ़ाइल संपादित करने से पहले दो संग्रहण मॉडल अलग रखना उचित है।
क्रेडेंशियल अनुरोध का जवाब देने के दो तरीके
पहला मॉडल कोई व्यक्ति है जो टर्मिनल में क्रेडेंशियल टाइप करता है, या कोई प्रबंधन इंटरफ़ेस जो उन्हें सत्र के लिए रखता है। OpenVPN उस प्रति को रखता है ताकि अगली फिर से बातचीत का जवाब बिना दोबारा पूछे दे सके, और चेतावनी ठीक इसी के बारे में है। डिस्क पर कुछ भी शामिल नहीं है, इसलिए बचाने लायक एकमात्र चीज़ वह प्रक्रिया है जो मान रखती है। क्लाइंट बंद करें और प्रति उसके साथ चली जाती है।
दूसरा मॉडल auth-user-pass है जो किसी फ़ाइल की ओर इशारा करता है, जहाँ फ़ाइल ही भंडार है और मान की ज़रूरत होने पर क्लाइंट उसे पढ़ता है। यहाँ महत्वपूर्ण जोखिम प्रक्रिया की मेमोरी नहीं, बल्कि उस फ़ाइल की अनुमतियाँ और स्वामित्व है। शुरुआती चेतावनी कॉन्फ़िग के निर्देशों से आती है, आप पासवर्ड कैसे देते हैं इसकी जाँच से नहीं, इसलिए वह दोनों मॉडलों में दिखती है और किसी की ओर इशारा नहीं करती।
इस तुलना का बाकी हिस्सा उसी विभाजन से आता है: एक मॉडल के लिए मेमोरी प्रबंधन, दूसरे के लिए फ़ाइल प्रबंधन और प्रक्रिया पहचान।
auth-nocache वास्तव में क्या हटाता है
इंटरैक्टिव लॉगिन के साथ, --auth-nocache उपयोग के बाद संग्रहीत प्रति को मेमोरी से हटा देता है। लागत हर फिर से बातचीत अंतराल पर नया अनुरोध है, क्योंकि अगला दौर हटाई गई चीज़ का दोबारा उपयोग नहीं कर सकता।
फ़ाइल आधारित लॉगिन में क्लाइंट फ़ाइल को फिर पढ़ सकता है, इसलिए हटाना अधिकतर अदृश्य रहता है। यह उस एक जगह दिखाई देता है जहाँ लोग इसकी अपेक्षा नहीं करते: डेमन के विशेषाधिकार छोड़ने के बाद, यदि क्रेडेंशियल फ़ाइल उस खाते के लिए पढ़ने योग्य न हो जिसके अंतर्गत वह अब चल रहा है।
विकल्प इसलिए जोड़ें कि आप यह अदला-बदली समझते हैं, इसलिए नहीं कि चेतावनी दिखी। लॉग को शांत करने के लिए जोड़ा गया विकल्प वह विकल्प है जिसका असर किसी ने नहीं मापा।
फ़ाइल आधारित रास्ता कहाँ टूटता है
जो क्लाइंट टनल उपकरण खोलने के लिए root के रूप में शुरू होता है और फिर user और group पर जाता है, वह क्रेडेंशियल फ़ाइल दो बार पढ़ता है: एक बार बदलाव से पहले, एक बार उसके बाद की फिर से बातचीत में। यदि फ़ाइल मोड 600 में है और root की है, तो दूसरा पाठन विफल हो जाता है, और विफलता एक घंटे बाद सर्वर समस्या जैसी दिखने वाली प्रमाणीकरण त्रुटि के रूप में सामने आती है। फिर से बातचीत अंतराल के आसपास क्लाइंट लॉग देखें, फिर खाता और फ़ाइल साथ में देखें।
stat -c '%a %U:%G' /etc/openvpn/client.creds
ps -o user:12,args -C openvpn | headदोनों पंक्तियाँ मायने रखती हैं। पहली बताती है कि फ़ाइल कौन पढ़ सकता है, दूसरी बताती है कि चल रहा डेमन वास्तव में कौन है, और उनके बीच का अंतर ऐसी विफलता समझाता है जिसे पासवर्ड दोबारा लिखने से ठीक नहीं किया जा सकेगा।
व्यावहारिक सुधार बिना चमक के हैं: फ़ाइल को ऐसी निर्देशिका और स्वामी के पास ले जाएँ जिसे डेमन का खाता पढ़ सके, या विशेषाधिकार प्राप्त पाठन रखें और पुष्टि करें कि आपका क्लाइंट केवल एक बार पढ़ता है। फ़ाइल को सबके लिए पढ़ने योग्य बनाकर इसे हल न करें।
वह मामला जिसे वाकई विकल्प चाहिए
एकबारगी कोड ले जाने वाला लॉगिन auth-nocache किसी दूसरे कारण से चाहता है। एकबारगी कोड पहले प्रमाणीकरण में खर्च हो जाता है, इसलिए कैश की गई प्रति अगली फिर से बातचीत में बेकार है और पुराना मान दोबारा चलाया भी जा सकता है।
यह क्रेडेंशियल के प्रकार का सवाल है, यह नहीं कि वह कहाँ संग्रहीत है। सुरक्षित फ़ाइल में स्थिर पासवर्ड का उल्टा स्वरूप होता है: उसे हर फिर से बातचीत में पढ़ने योग्य होना चाहिए, और जो सुरक्षा चाहिए वह फ़ाइल पर है।
इन दो कारणों को प्रोफ़ाइल टिप्पणियों में अलग रखें, वरना अगला प्रशासक मान लेगा कि विकल्प उसी कारण से है जो वह चुनता।
एक निर्णय में तुलना
इंटरैक्टिव मॉडल तब चुनें जब कोई व्यक्ति मौजूद हो और ताज़गी मायने रखती हो, और बार-बार अनुरोध को उसकी लागत मानें। फ़ाइल मॉडल तब चुनें जब क्लाइंट बिना निगरानी चलता हो, और मेहनत स्वामित्व, मोड और विशेषाधिकार छोड़ने पर लगाएँ।
कोई भी मॉडल संग्रहीत पासवर्ड को अपने आप सुरक्षित नहीं बनाता, और कोई भी शुरुआती चेतावनी को अर्थपूर्ण नहीं बनाता।
यदि चेतावनी ही प्रोफ़ाइल खोलने का एकमात्र कारण थी, तो अस्पष्ट विकल्प के बजाय निर्णय लिखें: क्रेडेंशियल ऐसी फ़ाइल से आते हैं जिसे डेमन का खाता पढ़ सकता है, फिर से बातचीत सफल होते देखी गई है, और OpenVPN 2.6 मार्गदर्शिका का फिर से बातचीत वाला भाग अंतराल बदलने से पहले पढ़ा गया। वह टिप्पणी किसी भी एक फ़्लैग से अधिक टिकती है।