SSH कुंजी का पासफ़्रेज़ फ़ाइल की रक्षा करता है, मार्ग की नहीं

पुराने लैपटॉप की एक बैकअप ड्राइव में अब भी निजी SSH कुंजी है, और कोई पूछता है कि क्या VPN उसकी रक्षा करता है। नहीं करता, और कभी नहीं किया। VPN दो नेटवर्कों के बीच के मार्ग की रक्षा करता है; पासफ़्रेज़ फ़ाइल की रक्षा करता है; एजेंट चल रहे सत्र की रक्षा करता है। तीन अलग तंत्र, तीन अलग विफलता विधियाँ, और चोरी हुई प्रति केवल पहले दो की परवाह करती है।

पासफ़्रेज़ फ़ाइल का है

SSH कुंजी का पासफ़्रेज़ विश्राम में पड़ी निजी कुंजी सामग्री को एन्क्रिप्ट करता है। यह सर्वर को भेजा जाने वाला खाता पासवर्ड नहीं है, और VPN से जुड़ने के लिए उपयोग किया जाने वाला क्रेडेंशियल नहीं है। इन्हें मिलाने से ऐसे बदलाव होते हैं जो जोखिम का समाधान नहीं करते।

OpenSSH का ssh-keygen मैनुअल पासफ़्रेज़ को संभालने को कवर करता है, जिसमें -p स्विच भी है जो पहले से मौजूद कुंजी पर नया पासफ़्रेज़ सेट करता है।

मौजूदा कुंजी के लिए आदेश का रूप सरल है, और यह फ़ाइल को फिर से लिखता है:

ssh-keygen -p -f ~/.ssh/id_ed25519

कुंजी के स्वामी की स्वीकृत रखरखाव और पुनर्प्राप्ति प्रक्रिया का उपयोग करें, क्योंकि यह लेखन है, निरीक्षण नहीं। निजी फ़ाइल प्रकाशित न करें और साझा आदेश पंक्ति पर असली पासफ़्रेज़ न रखें। पासफ़्रेज़ बदलने से पहले ली गई प्रति फिर से एन्क्रिप्ट नहीं होती। पुरानी प्रति का स्थान टिकट में दर्ज करें ताकि स्वामी तय कर सके कि उसे नष्ट करना है या नहीं।

प्रति लैपटॉप और सुरंग से अधिक जीती है

कुंजी फ़ाइल की प्रति बन जाने के बाद लैपटॉप का चलता VPN कनेक्शन उसके बारे में कुछ नहीं कहता। महत्वपूर्ण यह है कि फ़ाइल स्वयं कितनी अच्छी तरह सुरक्षित है, और कौन से सर्वर अब भी मिलती हुई सार्वजनिक कुंजी पर भरोसा करते हैं।

वर्तमान फ़ाइल पर पासफ़्रेज़ बदलने से प्रति को छूता नहीं, और सर्वर पर authorized_keys से वही सार्वजनिक कुंजी हटती नहीं। निरस्तीकरण और पुनः एन्क्रिप्शन अलग क्रियाएँ हैं।

इसलिए लीक हुई निजी कुंजी को नेटवर्क घटना नहीं, पहचान घटना मानें। स्वीकृत कुंजी को उन सर्वरों और नामांकन प्रक्रिया के माध्यम से हटाएँ या बदलें जो उसके स्वामी हैं। VPN रोकना एक क्षण में एक मार्ग सीमित करता है; यह निरस्तीकरण नहीं है।

अनलॉक करना रहस्य को एजेंट में ले जाता है

एजेंट बाद के प्रमाणीकरण के लिए डिक्रिप्ट की गई पहचान रखता है, ताकि उपयोगकर्ता हर कनेक्शन पर पासफ़्रेज़ फिर से न लिखे। यह अपनी सुरक्षा सीमा वाली सुविधा है।

ssh-agent अपने -t विकल्प के ज़रिए सीमित कर सकता है कि कोई पहचान कितनी देर लोड रहे, और प्रति-पहचान सेटिंग उस सीमा को पार कर सकती है। VPN डिस्कनेक्ट होने पर हर लोड की गई कुंजी भूल जाती है मानने के बजाय उस एजेंट के लिए नीति चुनें जिसे आप वास्तव में चलाते हैं।

कुंजी अनलॉक होने के बाद समझौता हुई प्रक्रिया चोरी हुई एन्क्रिप्टेड फ़ाइल से अलग समस्या है। एजेंट को दूसरे होस्ट पर अग्रेषित करना कुंजी फ़ाइल की प्रतिलिपि बिना प्रमाणीकरण क्षमता सौंपता है, इसलिए इसे केवल स्वीकृत आवश्यकता के लिए सक्षम करें।

बदलाव से पहले और बाद में सूची बनाएँ कि एजेंट के पास अभी क्या है:

ssh-add -l

बिना निगरानी वाले कार्यों को अपनी योजना चाहिए

निर्धारित कार्य किसी संकेत का उत्तर नहीं दे सकता। उसे स्वीकृत मशीन-क्रेडेंशियल व्यवस्था चाहिए, और अनलॉकिंग रहस्य को कुंजी के उसी निर्देशिका में रखना, जिसे वही खाता पढ़ सके, दूसरी सीमा नहीं बनाता।

समर्थित रहस्य वितरण या हार्डवेयर-आधारित संचालन पर सेवा स्वामी के साथ काम करें, और नवीनीकरण, विफलता तथा पुनर्प्राप्ति को कवर करें। कीबोर्ड पर मनुष्य चाहना विफलता का रूप बदल देता है, उस होस्ट की तुलना में जो बिना किसी के देखे बूट होता है।

सर्वर की होस्ट-पहचान जाँच और उसके खाता प्रतिबंध भी रखें। VPN मार्ग आपको निजी रास्ता देता है; यह सिद्ध नहीं करता कि आप जिस भी SSH श्रोता तक पहुँचते हैं वही इच्छित होस्ट है। श्रोता और होस्ट कुंजी की फ़िंगरप्रिंट को कुंजी की तरह उसी सूची में दर्ज करें।

सीमाओं को अलग-अलग सत्यापित करें

हर सीमा को उसके अपने प्रश्न से जाँचें। क्या फ़ाइल पासफ़्रेज़ के बिना खुलती है? क्या डिस्कनेक्ट के बाद भी एजेंट पहचान रखता है? क्या सर्वर अब भी सार्वजनिक कुंजी स्वीकार करता है?

दो आदेश पहले और तीसरे का उत्तर देते हैं:

ssh-keygen -y -f ~/.ssh/id_ed25519
ssh -v [email protected]

फ़ाइल सुरक्षा, अनुमत कुंजी उपयोग और सर्वर-पक्ष हटाने को तीन अलग पंक्तियों के रूप में दर्ज करें। सुरंग, पासफ़्रेज़ और एजेंट में से हर एक संबंध का अलग हिस्सा पहरा देता है, और उनमें से केवल एक नेटवर्क के बारे में है।