OpenVPN systemd के पासवर्ड अनुरोध की प्रतीक्षा कर रहा है: क्या आपको उत्तर देना चाहिए?
systemd का पासवर्ड संकेत किसी सेवा का अनुरोध है, गेटवे का फ़ैसला नहीं। तय करें कि कौन-सा रहस्य माँगा जा रहा है और किसे उत्तर देना चाहिए।
टर्मिनल में systemd-tty-ask-password-agent के बारे में एक संदेश दिखाई देता है, और टनल ऊपर नहीं है। लुभावना पाठ यह है कि VPN ने पासवर्ड अस्वीकार कर दिया और अब कुछ सुधार की प्रतीक्षा कर रहा है। अधिक सटीक यह है कि किसी सेवा ने systemd से इंटरैक्टिव इनपुट माँगा है, और उस अनुरोध का उत्तर अभी नहीं दिया गया है। किस सेवा ने माँगा और कौन-सा रहस्य चाहती है, ये दो प्रश्न आप कुछ भी टाइप करने से पहले सुलझा सकते हैं।
किसे उत्तर देना चाहिए, यह दो शर्तें तय करती हैं
पहली शर्त यह है कि क्या आपने इस इंस्टेंस को जानबूझकर शुरू किया था। आपकी किसी कार्रवाई के बाद आने वाला अनुरोध आपका है, और बिना मेल खाती कार्रवाई के दिखने वाला अनुरोध किसी और चीज़ का है। दूसरी यह है कि रहस्य खाता प्रमाणीकरण है या कुंजी सुरक्षा, क्योंकि ये अलग-अलग जगहों पर रहते हैं और अलग-अलग कोड पथों से गुज़रते हैं। कार्य करने से पहले देखें तो दोनों उत्तर जर्नल में दिखाई देते हैं।
जब दोनों उत्तर स्पष्ट हों, तो निर्णय सरल है: सेवा के अपने समर्थित संकेत पथ से उत्तर दें। जब कोई एक अस्पष्ट हो, तो सही कदम जाँच करना है, ऐसे संकेत में पासवर्ड टाइप करना नहीं जिसे आप किसी से जोड़ नहीं सकते।
यही पूरा नियम है, और आदेशों से पहले इसे कहना उचित है। नीचे का सब कुछ इसी से निकलता है।
कुछ भी टाइप करने से पहले अनुरोध की सूची देखें
एजेंट बिना किसी को उत्तर दिए सूचीबद्ध कर सकता है कि क्या लंबित है। sudo systemd-tty-ask-password-agent --list लंबित अनुरोधों को छापता है, और वही आउटपुट वह साक्ष्य है जो किसी संकेत को किसी यूनिट से जोड़ने के लिए चाहिए। क्रेडेंशियल देने से पहले इसे पढ़ें, और अनुरोधों के विवरण को किसी भी सार्वजनिक नैदानिक पेस्ट से बाहर रखें।
सूची को उस क्रिया से और उस यूनिट से मिलाएँ जो उसकी मालिक है। यदि सूची में कुछ भी आपकी कार्रवाई से मेल नहीं खाता, तो जो संकेत आपने देखा वह किसी दूसरी सेवा का है और उसे सुलझाना आपका काम नहीं है। सूची में यूनिट का नाम ही संकेत और सेवा के बीच एकमात्र भरोसेमंद कड़ी है।
ऐसे अनुरोध का उत्तर न दें जिसे आप किसी से जोड़ नहीं सकते। प्रतीक्षा की कीमत देरी है, जबकि ग़लत संकेत का उत्तर देने की कीमत ग़लत जगह पर क्रेडेंशियल है।
इंस्टेंस को वास्तव में कौन-सा रहस्य चाहिए?
auth-user-pass VPN सेवा के खाता प्रमाणीकरण से संबंधित है, और क्रेडेंशियल फ़ाइल के बिना प्रलेखित व्यवहार कंसोल पर पूछना है। askpass इसके बजाय वह पासफ़्रेज़ प्राप्त करता है जो सुरक्षित कुंजी सामग्री खोलता है, और यह प्रक्रिया पृष्ठभूमि में जाने से पहले ही करता है। ये अलग-अलग आयु वाले अलग-अलग रहस्य हैं।
फ़ाइल स्वरूप भी अलग हैं। खाता रूप एक उपयोगकर्ता नाम पंक्ति और एक पासवर्ड पंक्ति की अपेक्षा करता है, जबकि कुंजी-पासफ़्रेज़ फ़ाइल पहली पंक्ति को अपना पासवर्ड मानकर पढ़ती है। दूसरी भूमिका की क्रेडेंशियल फ़ाइल की विधि की नकल आमतौर पर समाधान के बजाय एक और संकेत पैदा करती है। ग़लत आकार की फ़ाइल फ़ाइल न होने से बुरी है, क्योंकि विफलता ऐसी जगह चली जाती है जहाँ कोई नज़र नहीं रखता।
यह तय करने से पहले कि क्या टाइप करना है, देखें कि इंस्टेंस कौन-सा निर्देश उपयोग करता है। निर्देश का नाम ही बताता है कि संकेत किस रहस्य के लिए है।
--query क्या करता है जो --list नहीं करता
--query कॉल करने वाले टर्मिनल पर हर लंबित अनुरोध को संसाधित करता है, जो एक संकेत का उत्तर देने से कहीं अधिक व्यापक कार्रवाई है। यह OpenVPN चयनक नहीं है, और व्यस्त मशीन पर यह अन्य यूनिटों के अनुरोधों का उत्तर दे सकता है। देखरेख मोड और भी व्यापक है, क्योंकि यह अनुरोध आते ही उन्हें संसाधित करता रहता है।
वही सबसे सँकरा तंत्र उपयोग करें जो काम करे। एक सेवा के लिए, उस सेवा का अपना संकेत प्रवाह वैश्विक एजेंट से सँकरा है, और उत्तर को पूछने वाली यूनिट से जुड़ा रखता है।
एक बार कोई सूचना दिखने के कारण एकबारगी अनुरोध को बिना देखरेख वाला वैश्विक एजेंट बना देना — इसी तरह अस्थायी झंझट स्थायी डिज़ाइन बन जाता है। यही सावधानी पूरे होस्ट पर पासवर्ड-सूचना यूनिटों को अक्षम करने पर भी लागू होती है।
निर्णय लें, फिर चुनाव दर्ज करें
बिना देखरेख वाली तैनाती के लिए, कनेक्शन के मालिक के साथ क्रेडेंशियल स्रोत, फ़ाइल अनुमतियाँ और नवीनीकरण समय-सारिणी पर सहमत हों। इंटरैक्टिव दूसरे कारक के लिए किसी व्यक्ति या समर्पित सेवा पहचान की ज़रूरत हो सकती है। संकेत को दबाने से वह प्रमाणीकरण पैदा नहीं होता, और auth-user-pass हटाने से केवल वही सेवा टूटती है जिसे इसकी ज़रूरत है।
इंटरैक्शन के बाद, उसी इंस्टेंस को उसकी अगली घटना के लिए देखें और निजी संसाधन का परीक्षण करें। यदि कुछ भी लंबित नहीं है, तो होस्ट पर हर OpenVPN यूनिट शुरू करने के बजाय इंस्टेंस की स्थिति पर लौटें।