कुंजी का पासफ़्रेज़ हटाएँ या रखें? आप जो प्रतिलिपि बनाते हैं
बिना एन्क्रिप्ट की गई कुंजी फ़ाइल वही रहस्य कमज़ोर सुरक्षा के पीछे रखती है। बदलने से पहले विश्राम के जोखिम की तुलना करें, और जानें कि यह क्या पूर्ववत नहीं करता।
एन्क्रिप्ट की गई निजी कुंजी और बिना एन्क्रिप्ट की गई कुंजी एक ही कुंजी सामग्री रखती हैं। बदलना नई पहचान नहीं बनाता, VPN खाता रीसेट नहीं करता और पुरानी फ़ाइल को अमान्य नहीं करता। यह दूसरी प्रतिलिपि लिखता है, और वह प्रतिलिपि अलग विश्राम-जोखिम रखती है।
यह अदला-बदली फ़ायदेमंद है या नहीं, यह इस पर निर्भर करता है कि फ़ाइल कहाँ रहेगी और कौन उसे पढ़ सकेगा।
बदलाव वास्तव में क्या बदलता है
बदलने से पहले, कुंजी ऑपरेटर द्वारा दिए गए पासफ़्रेज़ से सुरक्षित रहती है। बदलने के बाद, यह फ़ाइलसिस्टम अनुमतियों और फ़ाइल के आसपास के किसी भी पहुँच नियंत्रण से सुरक्षित रहती है। क्रिप्टोग्राफ़ी नहीं बदली है; हमलावर और कुंजी के बीच की चीज़ों की संख्या बदली है। पूरी तुलना यही है।
एक तालिका अंतर को ठोस बनाती है।
| Form | What protects it | How it fails |
|---|---|---|
| Encrypted key | A passphrase plus file access | Weak passphrase, or an offline attack on the file |
| Unencrypted key | File permissions and host security only | Any reader copies it silently |
कोई भी रूप अपने आप अधिक सुरक्षित नहीं है। वे अलग-अलग तरह से विफल होते हैं, और उनमें से केवल एक तरीका लॉग में प्रविष्टि छोड़ता है।
कब पासफ़्रेज़ रखना बेहतर है
यदि कोई समर्थित क्लाइंट पासफ़्रेज़ माँग सकता है या अनुमोदित गुप्त भंडार से ला सकता है, तो बदलना कुछ नहीं खरीदता। आप एक प्रतिलिपि, एक सुरक्षा सीमा और निगरानी के लिए एक कम फ़ाइल रखते हैं। PEM कुंजियाँ स्वीकार करने वाले अधिकांश VPN क्लाइंट यह कर सकते हैं।
जब कोई टीम कुंजी साझा करती है तब भी बदलना गलत कदम है। साझा होस्ट पर बिना एन्क्रिप्ट की गई फ़ाइल ऐसा क्रेडेंशियल बन जाती है जिसे शेल पहुँच रखने वाला कोई भी कॉपी कर सकता है।
कब बिना एन्क्रिप्ट की गई प्रतिलिपि उचित है
कुछ सेवाएँ माँग नहीं सकतीं, कुछ कंटेनर गुप्त जानकारी को केवल-पढ़ने के रूप में माउंट करते हैं, और कुछ उपकरण बूट पर बिना किसी इंटरैक्टिव रास्ते के कुंजी फ़ाइल पढ़ते हैं। ऐसे मामलों में, ठीक से सीमित निर्देशिका में बिना एन्क्रिप्ट की गई कुंजी समर्थित डिज़ाइन हो सकती है। औचित्य परिवेश है, सुविधा नहीं।
यदि आप नहीं बता सकते कि फ़ाइल कौन पढ़ सकता है और क्यों, तो उत्तर नहीं है।
कमांड और उसके तीखे किनारे
OpenSSL 3.5 द्वारा समर्थित फ़ाइल-आधारित कुंजी के लिए, pkey संदर्भ पासफ़्रेज़ हटाने और इंटरैक्टिव संकेत का दस्तावेज़ीकरण करता है जब इनपुट एन्क्रिप्ट किया गया हो और कोई पासवर्ड स्रोत न दिया गया हो। न्यूनतम रूप छोटा है, और इसे लापरवाही से चलाना आसान है।
umask 077
openssl pkey -in protected-key.pem -out new-private-key.pemतीन तीखे किनारे। आउटपुट फ़ाइल I/O परमाणु नहीं है, इसलिए मौजूदा आउटपुट पथ लेखन के बीच में कट सकता है। इनपुट पथ को आउटपुट के रूप में उपयोग न करें, और एकमात्र सुरक्षित प्रतिलिपि पर प्रयोग न करें। पासफ़्रेज़ कमांड लाइन पर नहीं, संकेत पर दर्ज करें, जहाँ वह शेल इतिहास में चला जाता है।
कोई भी VPN कॉन्फ़िगरेशन बदलने से पहले परिणाम जाँचें: openssl pkey -in new-private-key.pem -pubout को वही सार्वजनिक कुंजी प्रिंट करनी चाहिए जो आपके पास पहले थी।
बदलाव क्या नहीं करता
यह एन्क्रिप्ट की गई प्रतिलिपि को रद्द नहीं करता, जो अब भी वहीं मौजूद है जहाँ आपने उसे छोड़ा था। यह VPN खाते का पासवर्ड या प्रमाणपत्र नहीं बदलता। और यह पहले ही हो चुके खुलासे को ठीक नहीं करता। यदि कुंजी लीक हुई है, तो समाधान प्रतिस्थापन और सर्वर-साइड निरसन है, स्थानीय फ़ॉर्मैट परिवर्तन नहीं।
मध्यवर्ती फ़ाइल को जानबूझकर हटाएँ, और पुष्टि करें कि आप जो पथ हटा रहे हैं वह वही है जो आपने बनाया था।