NetworkManager को सहेजा हुआ VPN पासवर्ड दिखाने से रोकें
हर बार पूछें, इसे कीरिंग को सौंपें, या केवल root के लिए फ़ाइल रखें। हर विकल्प का जोखिम अलग है, और पासवर्ड फ़्लैग उससे मेल खाना चाहिए।
NetworkManager एक VPN पासवर्ड रख सकता है ताकि कनेक्शन बिना किसी के टाइप किए आ जाए, और वह उस मान को एडिटर या nmcli --show-secrets के ज़रिए फिर से दिखा सकता है। तीन स्वामित्व मॉडल उपलब्ध हैं, और प्रदर्शन व्यवहार केवल इस बात का लक्षण है कि आपने कौन-सा चुना। पहले मॉडल चुनें, फिर उससे मेल खाता फ़्लैग सेट करें, न कि किसी प्लेसहोल्डर से फ़ील्ड छिपाएँ जो अगले व्यक्ति को भ्रमित करेगा।
तीन स्वामित्व मॉडल
पहला मॉडल हर बार पूछता है। कुछ भी संग्रहीत नहीं होता, रहस्य केवल सक्रियण की अवधि तक रहता है, और जो भी कनेक्शन शुरू करता है उसे पासवर्ड पता होना चाहिए। यह सबसे कम सुविधाजनक विकल्प है और बचाव के लिए सबसे आसान है।
दूसरा रहस्य को उपयोगकर्ता के स्वामित्व वाली कीरिंग को सौंपता है। एजेंट सत्र शुरू होने पर अनलॉक होता है और मांग पर मान देता है, जिससे वह कनेक्शन फ़ाइल से बाहर रहता है पर कनेक्शन को उस उपयोगकर्ता के सत्र से बाँध देता है। इससे दो शर्तें निकलती हैं: एजेंट चल रहा हो, और वह अनलॉक हो।
तीसरा किसी सिस्टम कनेक्शन के लिए संरक्षित क्रेडेंशियल संग्रहीत करता है। यह रीबूट के बाद भी बना रहता है और किसी के लॉग इन करने से पहले काम करता है, और बदले में मान डिस्क पर फ़ाइल अनुमतियों से सुरक्षित रहता है, एन्क्रिप्शन से नहीं।
हर मॉडल सही संदर्भ में उचित है। गलती उन्हें मिलाने की है, और इसी तरह लैपटॉप में रहस्य दो जगह रह जाता है और यह स्पष्ट उत्तर नहीं रहता कि कौन-सा प्रामाणिक है। लिख लें कि कोई प्रोफ़ाइल कौन-सा मॉडल उपयोग करती है। टीम की रनबुक में एक पंक्ति अगले व्यक्ति को चौथी खोज की जगह गढ़ने से बचाती है।
बदलने से पहले वर्तमान स्थिति पढ़ें
कनेक्शन प्रबंधित करने वाले उपयोगकर्ता के रूप में प्रोफ़ाइल और रहस्य की स्थिति देखें। दूसरा आदेश वही है जो बताता है कि मान वास्तव में पढ़ने योग्य है या नहीं।
nmcli connection show "Office VPN"
nmcli --show-secrets connection show "Office VPN"
sudo stat -c '%U %a %n' /etc/NetworkManager/system-connections/*.nmconnectionउस डायरेक्टरी की कुंजी फ़ाइल सामान्यतः root के स्वामित्व में मोड 600 के साथ होती है। यह सामान्य उपयोगकर्ताओं को बाहर रखता है और root को बाहर नहीं रखता, जो तब मायने रखता है जब वही मशीन साझा हो या जब बैकअप root के रूप में चले।
फ़ाइल अनुमतियाँ एक सीमा हैं, एन्क्रिप्शन नहीं। जो root के रूप में फ़ाइल पढ़ सकता है, उसके पास पासवर्ड स्पष्ट पाठ में है। यह बिना निगरानी वाले सर्वर के लिए स्वीकार्य सौदा है और साझा वर्कस्टेशन के लिए ख़राब। एक बार लिख लेने से इस बहस से बचा जा सकता है कि मान संरक्षित है या नहीं।
हर फ़्लैग मान क्या करता है
VPN रहस्य में flags नामक गुण होता है, और मान केवल संख्याओं से स्पष्ट नहीं होते।
| Value | Meaning | Practical effect |
|---|---|---|
| 0 | No special flag | Secret is typically saved with the connection |
| 1 | Agent-owned | A keyring or secret agent supplies it |
| 2 | Not saved | Prompted at each activation |
| 4 | Not required | Connection proceeds without asking |
वास्तविक व्यवहार प्लगइन पर और इस पर भी निर्भर करता है कि एजेंट चल रहा है या नहीं, इसलिए तालिका को अनुबंध और देखे गए व्यवहार को वह चीज़ मानें जिसे आप सत्यापित करते हैं। एक डेस्कटॉप पर काम करने वाला मान बिना सत्र वाले सर्वर पर अलग व्यवहार कर सकता है। भ्रमित करने वाले अधिकांश टिकट इसी अंतराल में रहते हैं।
पंक्ति हटाकर आशा करने के बजाय गुण को स्पष्ट रूप से सेट करें। अनुपस्थित फ़्लैग कोई नीति नहीं है, और अगला पैकेज अपडेट उसे किसी ऐसी चीज़ से भर सकता है जिसका आपने इरादा नहीं किया।
मॉडल को कनेक्शन के शुरू होने के समय से मिलाएँ
यदि कनेक्शन केवल तब शुरू होता है जब कोई उपयोगकर्ता लॉग इन हो, तो एजेंट स्वामित्व अच्छी तरह बैठता है और रहस्य को फ़ाइल से बाहर रखता है। यदि यह बूट पर, किसी सत्र के होने से पहले शुरू होता है, तो एजेंट आपकी मदद नहीं कर सकता।
अधिकांश मशीनों के लिए पूरा निर्णय यही है। यह भ्रमित रिपोर्टों के एक वर्ग को भी समझाता है जहाँ कनेक्शन इंटरैक्टिव रूप से काम करता है और रीबूट के बाद विफल हो जाता है। फ़्लैग कभी नहीं बदला; संदर्भ बदल गया।
बिना निगरानी वाले मामले में व्यावहारिक उत्तर root के स्वामित्व वाली प्रतिबंधित फ़ाइल या स्वीकृत क्रेडेंशियल स्रोत है। इसे कनेक्शन प्रोफ़ाइल से बाहर रखें यदि वह प्रोफ़ाइल कभी निर्यात हो या किसी अन्य मशीन पर कॉपी हो।
यदि मान पहले से दिखाई दे रहा था, तो उसे बदलें
फ़्लैग बदलने से पासवर्ड स्वयं अछूता रहता है। स्क्रीनशॉट में, shell इतिहास में, सपोर्ट को भेजे गए बंडल में, या ऐसी फ़ाइल में जिसे अन्य उपयोगकर्ता खोल सकते थे, जो मान सामने आया हो उसे प्रकट माना जाना चाहिए।
इसे सर्वर पर बदलें, फिर क्लाइंट ठीक करें और पुराने से प्रमाणित हुए किसी भी सत्र को समाप्त करें। स्थानीय कनेक्शन हटाने से दूसरी ओर कुछ भी रद्द नहीं होता, और लोग यही हिस्सा चूक जाते हैं।
फिर पासवर्ड को कमांड लाइन पर रखना बंद करें। वह shell इतिहास में चला जाता है और प्रक्रिया सूची में दिख सकता है; इसके बजाय इंटरैक्टिव प्रॉम्प्ट या एजेंट का उपयोग करें।
फिर से कनेक्ट करके सत्यापित करें
जिस आदेश ने रहस्य दिखाया उसे दोहराएँ और पुष्टि करें कि फ़ील्ड अब छपता नहीं है। फिर डिस्कनेक्ट और पुनः कनेक्ट करें, और यदि कनेक्शन स्वचालित रूप से शुरू होता है तो रीबूट करें, क्योंकि दिलचस्प विफलता केवल तब दिखती है जब सत्र संदर्भ बदलता है।
यदि रहस्य अब भी दिखता है, तो कोई अन्य प्रोफ़ाइल या अन्य एजेंट उसे दे रहा है। फ़ाइलें हटाने के बजाय सक्रिय कनेक्शन और कीरिंग जाँचें, जब तक लक्षण न हटे।