SSH एजेंट फ़ॉरवर्डिंग बनाम कुंजी की प्रतिलिपि: वास्तव में क्या लीक होता है

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

सार्वजनिक कुंजी से लॉगिन कुंजी नहीं, हस्ताक्षर भेजता है

प्रमाणीकरण का आदान-प्रदान उपयोगकर्ता की सार्वजनिक कुंजी और सत्र-डेटा पर एक हस्ताक्षर ले जाता है। सर्वर उस हस्ताक्षर को उसी कुंजी से जाँचता है जिस पर उसे पहले से भरोसा है, इसलिए निजी आधा हिस्सा अविश्वसनीय नेटवर्क पर भी क्लाइंट पर रह सकता है। टनल देखने वाला VPN ऑपरेटर किसी भी हाल में एन्क्रिप्टेड SSH सत्र देखता है।

यह प्रोटोकॉल का वर्णन है, रास्ते के हर सिरे की विश्वसनीयता का नहीं। होस्ट-पहचान सत्यापन अक्षुण्ण रखें, क्योंकि कोई भी होस्ट कुंजी स्वीकार करने वाला क्लाइंट यहाँ चर्चित नियंत्रण से भिन्न नियंत्रण छोड़ चुका है। पकड़ा गया सत्र और पकड़ी गई कुंजी अलग निष्कर्ष हैं, और इनमें से केवल एक ही क्रेडेंशियल की हानि है। दोनों को रिपोर्ट में अलग वाक्यों में रखें।

ssh-keygen -lf ~/.ssh/id_ed25519.pub
ssh -o StrictHostKeyChecking=yes [email protected]

पहला आदेश सार्वजनिक फ़िंगरप्रिंट छापता है ताकि आप उसे सर्वर की सूची से मिला सकें। दूसरा उस डिफ़ॉल्ट पर भरोसा करने के बजाय होस्ट-कुंजी जाँच को स्पष्ट बनाता है जिसे किसी ने पढ़ा ही नहीं। कुंजियों के बारे में कुछ बदलने से पहले दोनों चलाएँ, ताकि आधार-रेखा दर्ज हो।

एजेंट फ़ॉरवर्डिंग हस्ताक्षर करने की क्षमता सौंपती है

फ़ॉरवर्डिंग चालू होने पर दूरस्थ होस्ट पर एक सॉकेट दिखता है और स्थानीय एजेंट उससे आने वाले अनुरोधों का उत्तर देता है। सत्र के दौरान उस सॉकेट का उपयोग कर सकने वाला कोई भी व्यक्ति उन होस्टों के सामने आपके रूप में प्रमाणित हो सकता है जो लोड की गई पहचानों को स्वीकार करते हैं। इसके काम करने के लिए कोई निजी कुंजी नेटवर्क पार नहीं करती।

जोखिम क्षमता है, फ़ाइल नहीं। इसीलिए फ़ॉरवर्डिंग किसी नामित कार्य और नामित होस्ट की है, लैपटॉप के हर कनेक्शन की नहीं। बिना फ़ॉरवर्ड किए एजेंट के कनेक्शन आगे भेजने वाला जंप होस्ट आमतौर पर आवश्यकता को पूरी तरह हटा देता है।

ssh-add -l
ssh -o ForwardAgent=no [email protected]
ssh -J [email protected] [email protected]

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

जो प्रमाण आपके पास है उसी से प्रतिक्रिया चुनें

जिस हस्ताक्षर-पहचान को उजागर माना गया है, उसके लिए प्रतिस्थापन और निरसन की प्रक्रिया चाहिए, और उन सेवाओं से उसकी स्वीकृति हटानी चाहिए जो उस पर भरोसा करती थीं। अपने लैपटॉप पर प्रतिलिपि मिटाने से हर दूसरी प्रतिलिपि अछूती रह जाती है। सेवाओं से आरंभ करें, फिर क्लाइंट साफ़ करें।

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

कोई भी देखा गया निर्यात केवल यह सिद्ध करता है कि जिस तंत्र से आप डरते थे वह प्रकट नहीं हुआ। यह इस बारे में कुछ नहीं कहता कि उस सॉकेट के दूसरे छोर का होस्ट और क्या कर सकता था।

रिपोर्ट में नियंत्रण अलग रखें

निजी सामग्री की रक्षा करें, सीमित करें कि कौन उससे हस्ताक्षर माँग सकता है, दूसरे पक्ष की सत्यापित पहचान बनाए रखें। ये तीन नियंत्रण हैं जो एक-दूसरे को मजबूत करते हैं, और क्या हुआ यह समझाते समय इनमें से कोई दूसरे का स्थान नहीं लेता।

समझौता किया गया लैपटॉप या उस पर विशेषाधिकार प्राप्त अनुप्रयोग बहुत व्यापक प्रभाव-क्षेत्र वाला तीसरा मामला है। VPN मार्ग बदलने से यह हल नहीं होता और डिस्क से पढ़ी जा चुकी कुंजी पर भरोसा बहाल नहीं होता।

लिखें कि किस घटक पर भरोसा था, फ़ॉरवर्डिंग चालू थी या नहीं, और वास्तव में क्या देखा गया। वही अभिलेख अगले निर्णय को रक्षात्मक बनाता है, न कि लीक के अर्थ के बारे में अनुमान।