अविश्वसनीय VPN पर आपका SSH पासवर्ड असल में कौन देखता है?

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

कुछ भी टाइप करने से पहले प्राप्तकर्ता का नाम लें

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

दोनों दिशाओं को मन में अलग रखें। होस्ट कुंजी बताती है कि आप किस सर्वर तक पहुँचे। पासवर्ड या कुंजी प्रमाणीकरण बताता है कि सर्वर किस उपयोगकर्ता को स्वीकार करता है। दूसरे को सुधारने से पहला कभी ठीक नहीं होता।

होस्ट की पहचान, रिकॉर्ड और बातचीत जाँचें

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

ssh-keygen -F ssh.internal.example.net -f ~/.ssh/known_hosts
ssh -o StrictHostKeyChecking=yes ssh.internal.example.net

सर्वर की ओर, जिन फ़िंगरप्रिंट को आप प्रकाशित करने वाले हैं उन्हें याद से कॉपी करने के बजाय छापें। उन्हें चैनल के बाहर बाँटना ही पूरी बात है; होस्टनाम के साथ उसी चैट चैनल से चिपकाया गया फ़िंगरप्रिंट केवल यह साबित करता है कि दोनों एक ही जगह से आए हैं।

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
sudo sshd -T | grep -E 'hostkey|kexalgorithms|cipher'

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

सर्वर वास्तव में किन विधियों को स्वीकार करता है, यह पढ़ें

सर्वर किन प्रमाणीकरण विधियों की अनुमति देता है, यह जानना बताता है कि पासवर्ड असल में किसलिए है। जो होस्ट केवल सार्वजनिक कुंजियाँ स्वीकार करता है, उसके पास बचाने लायक कोई पासवर्ड विनिमय नहीं है, और जो होस्ट अब भी पासवर्ड स्वीकार करता है, वह विरासत में मिले डिफ़ॉल्ट के बजाय सोचे-समझे निर्णय का हक़दार है।

sudo sshd -T | grep -E 'passwordauthentication|pubkeyauthentication|permitrootlogin'

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

होस्ट-कुंजी चेतावनी को घटना के चरण की तरह संभालें

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

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

यह रनबुक क्या कवर नहीं करता

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

सामान्य स्थिति के साथ समाप्त करें: सत्यापित होस्ट, सुरक्षित परिवहन, सोच-समझकर चुनी गई प्रमाणीकरण विधि, और कोई अनावश्यक फ़ॉरवर्डिंग नहीं। यही संयोजन शीर्षक के प्रश्न का उत्तर है, और यह एक नहीं, चार निर्णय हैं।