OpenVPN सेवा निजी कुंजी का पासवर्ड माँगते समय रुक जाती है: कैसे ठीक करें
सेवा के पास टर्मिनल नहीं होता, इसलिए एन्क्रिप्टेड कुंजी को askpass और पढ़ने योग्य फ़ाइल चाहिए। कुंजी का पासफ़्रेज़ सर्वर लॉगिन से अलग रखें और unit जाँचें।
OpenVPN स्थानीय मशीन पर निजी कुंजी का पासफ़्रेज़ माँगता है, इसलिए काम करने वाली लॉगिन फ़ाइल उसका जवाब कभी नहीं देती। सेवा में टाइप करने के लिए टर्मिनल नहीं होता, और शुरुआत या तो अटक जाती है या जर्नल में ऐसी प्रविष्टि के साथ विफल होती है जो कारण नहीं, इनपुट का नाम बताती है। यहाँ दो रहस्य हैं, और unit को फिर से चालू करने से पहले हर एक को अपना पठनीय स्रोत चाहिए। नीचे का क्रम उन्हें अलग करता है, फिर वह पहचान जाँचता है जो वास्तव में हर फ़ाइल खोलती है।
दोनों अनुरोधों में फ़र्क करें
कुंजी का पासफ़्रेज़ स्थानीय निजी कुंजी को डिक्रिप्ट करता है; खाते के क्रेडेंशियल सर्वर के साथ सत्र को प्रमाणित करते हैं। ये अलग जगहों से आते हैं, अलग समय पर विफल होते हैं और अलग संदेश देते हैं। इन्हें मिलाने से लोग पासवर्ड रीसेट खोजने निकल जाते हैं जबकि खाता शामिल ही नहीं था। कोई भी विकल्प बदलने से पहले अनुरोध का पाठ पढ़ें, क्योंकि कौन-सा रहस्य गायब है, इसका एकमात्र भरोसेमंद संकेत शब्दावली ही है।
Community OpenVPN 2.x में askpass ऐसी फ़ाइल बताता है जिसकी पहली पंक्ति में कुंजी का पासफ़्रेज़ होता है, और auth-user-pass ऐसी फ़ाइल बताता है जिसमें एक पंक्ति में उपयोक्तानाम और अगली में पासवर्ड होता है। दोनों में से कोई फ़ाइल दूसरे विकल्प को संतुष्ट नहीं कर सकती। डेस्कटॉप ऐप या NetworkManager प्रोफ़ाइल दोनों को अपने गुप्त भंडार में रख सकते हैं, जिसे कमांड-लाइन क्लाइंट कभी नहीं पढ़ता, इसलिए कोई भी पथ लिखने से पहले नोट करें कि आप कौन-सा क्लाइंट कॉन्फ़िगर कर रहे हैं।
दोनों विकल्पों को पठनीय फ़ाइलों की ओर इंगित करें
जिस प्रोफ़ाइल को दोनों इनपुट चाहिए, वह अंत में तीन फ़ाइल संदर्भों पर पहुँचती है: एन्क्रिप्टेड कुंजी, उसे खोलने वाला पासफ़्रेज़ और लॉगिन युग्म। उन्हें CA और पहचान जाँचों को छुए बिना जोड़ें, क्योंकि वे तय करते हैं कि सर्वर कौन है और इस समस्या का हिस्सा नहीं हैं। यदि परिनियोजन खाते के क्रेडेंशियल बिलकुल नहीं उपयोग करता, तो auth-user-pass जोड़ने से ऐसा इनपुट बनता है जो कोई दे नहीं सकता।
key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.authबिना तर्क वाले विकल्प पथ वाले विकल्पों से अलग व्यवहार करते हैं, और सेवा में यह अंतर मायने रखता है। बिना तर्क का askpass अब भी कंसोल पढ़ता है, और केवल उपयोक्तानाम वाली auth-user-pass फ़ाइल अब भी पासवर्ड अनुरोध को प्रतीक्षा में छोड़ देती है। क्लाइंट के डेमन बन जाने के बाद वह टर्मिनल से इनपुट माँग ही नहीं सकता, इसलिए इस तरह कॉन्फ़िगर की गई सेवा शुरू नहीं होती।
पूर्ण पथ कार्यशील निर्देशिका का प्रश्न हटा देते हैं पर पहुँच नहीं देते। इसके बाद स्वामित्व, मोड और पथ-पारगमन आते हैं, और तीनों उसी खाते के विरुद्ध जाँचे जाते हैं जिसके अंतर्गत प्रक्रिया चलती है।
प्रोफ़ाइल से पहले unit का कॉन्फ़िगरेशन पढ़ें
इंस्टेंस कौन-सा कॉन्फ़िगरेशन लोड करेगा, यह unit तय करता है, वह फ़ाइल नहीं जिसे आप संपादित कर रहे थे। उसकी कमांड लाइन और सभी drop-in पढ़ें, फिर कार्यशील निर्देशिका से उस प्रोफ़ाइल तक जाएँ जो वास्तव में उपयोग हो रही है। किसी दूसरी .ovpn फ़ाइल में जोड़ा गया पासफ़्रेज़ संदर्भ इस इंस्टेंस के लिए कुछ नहीं बदलता।
तीन केवल-पठन कमांड इसका अधिकांश उत्तर देते हैं। पहला unit और सभी drop-in दिखाता है, दूसरा उस पहचान और सैंडबॉक्स सेटिंग्स को जो प्रक्रिया को बाँधती हैं, और तीसरा यह कि पिछली शुरुआत ने वास्तव में किस बात की शिकायत की। मेज़बान पर मौजूद इंस्टेंस नाम का उपयोग करें:
systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -bProtectHome और प्रोफ़ाइल के अपने user, group व chroot विकल्पों पर ध्यान दें। होम निर्देशिका के अंतर्गत कोई फ़ाइल आपके शेल में पठनीय हो सकती है और होम निर्देशिकाएँ छिपाए जाने पर सेवा के भीतर अदृश्य हो जाती है। जिस खाते से systemd शुरू होता है, वह हमेशा वही खाता नहीं होता जो अंत में कुंजी खोलता है।
साबित करें कि रनटाइम पहचान दोनों फ़ाइलें खोल सकती है
केवल मोड पढ़ना पर्याप्त नहीं है, क्योंकि पथ की हर निर्देशिका उसी पहचान के लिए पारगम्य होनी चाहिए। पथ को घटक-दर-घटक चलें, फिर प्रक्रिया जिस खाते का उपयोग करती है उस रूप में खोलना परखें। root के स्वामित्व वाली और मोड 600 वाली फ़ाइल केवल तब तक काम करती है जब तक प्रक्रिया root है, जो कई प्रोफ़ाइलों के विशेषाधिकार घटाने के बाद सही नहीं रहता। दो कमांड पारगमन और खोलना दोनों ढकते हैं:
namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readableपहला कमांड हर घटक का मोड दिखाता है और वहाँ विफल होता है जहाँ खाता पार नहीं कर सकता; दूसरा उस एकमात्र महत्वपूर्ण प्रश्न का उत्तर देता है कि रनटाइम पहचान फ़ाइल को पढ़ने के लिए खोल सकती है या नहीं। दोनों में से कोई फ़ाइल की विषयवस्तु नहीं दिखाता, और फ़ाइल में पासफ़्रेज़ होने पर यही मुख्य बात है। लॉगिन फ़ाइल के लिए भी परीक्षण दोहराएँ, क्योंकि दोनों अक्सर अलग स्वामित्व के साथ संग्रहीत होती हैं।
यदि प्रक्रिया chroot या सीमित namespace का उपयोग करती है, तो वही परीक्षण उस दृश्य के भीतर से चलाएँ, अन्यथा उत्तर गलत फ़ाइलतंत्र का वर्णन करता है। छिपी होम निर्देशिका के नीचे संग्रहीत पासफ़्रेज़ ऐसे परीक्षण का सामान्य उदाहरण है जो unit के बाहर पास होता है और भीतर विफल।
पहली शुरुआत जाँचें, फिर पुनः कनेक्शन
इंस्टेंस को एक बार शुरू करें और पहली विफलता पढ़ें, आखिरी नहीं। गायब इनपुट फ़ाइल, विफल कुंजी डिक्रिप्शन और सर्वर की ओर से AUTH_FAILED तीन अलग घटनाएँ हैं, तीन अलग मरम्मतों के साथ। अनुमति की चेतावनी ठीक करना इस बात को साबित नहीं करता कि कुंजी खुली थी।
जर्नल की पंक्ति बताती है कि तीन में से कौन-सी स्थिति आपके पास है। मरम्मत इससे निकलती है कि कौन-सा इनपुट विफल हुआ:
| What the journal shows | Which input failed | Where to look |
|---|---|---|
| A path that cannot be opened | The file the profile names | Askpass or login path, and the unit's working directory |
| A key decryption error | The key passphrase | First line of the askpass file, and read access for the runtime identity |
AUTH_FAILED from the server | The account credentials | Login file contents, and whether the account is still valid |
फिर वह जीवनचक्र जो वास्तव में आपको चाहिए परखें: बूट पर शुरुआत और कोई भी समर्थित पुनः कनेक्शन, केवल अपने शेल से हाथ से शुरू करना नहीं। auth-nocache के साथ इनपुट पहले उपयोग के बाद छोड़ दिए जाते हैं, इसलिए बाद के पुनः कनेक्शन को अब भी पठनीय स्रोत चाहिए। डेस्कटॉप लॉगिन पर खुलने वाला keyring ऐसी सेवा के लिए उपलब्ध नहीं होता जो किसी के लॉगिन से पहले शुरू हुई हो, और हाथ का परीक्षण पास होकर रीबूट विफल होने का यही सामान्य कारण है। यदि पहली शुरुआत सफल हो और बाद का पुनः कनेक्शन विफल, तो अनुमतियाँ फिर बदलने से पहले पुनः कनेक्शन घटना के लिए जर्नल पढ़ें।
कुंजी के बगल में पासफ़्रेज़ रखने से एन्क्रिप्शन जो देता है वह घट जाता है, इसलिए उस फ़ाइल और उसके बैकअप को सीमित रखें। कुंजी का पासफ़्रेज़ हटाना गायब इनपुट की मरम्मत नहीं, अलग क्रेडेंशियल निर्णय है। मानव स्वीकृति या इंटरैक्टिव MFA पर निर्भर परिनियोजन को अपना समर्थित एजेंट या प्रबंधन एकीकरण चाहिए; स्थायी रूप से सहेजा गया एकबारगी कोड समतुल्य विकल्प नहीं है।