मैं पिछले 16 महीनों से इस समस्या का समाधान खोज रहा हूं। लेकिन हर बार जब मैं देखता हूं, तो एसएसएच प्रोटोकॉल के साथ ऐसा करना असंभव लगता है जैसा कि प्रासंगिक आरएफसी में निर्दिष्ट है और प्रमुख कार्यान्वयन द्वारा कार्यान्वित किया जाता है।
हालाँकि यदि आप थोड़ा संशोधित SSH क्लाइंट का उपयोग करने के लिए तैयार हैं और आप प्रोटोकॉल का उपयोग करने के लिए तैयार हैं, जो कि जब वे डिज़ाइन किए गए थे, तब इसका कोई इरादा नहीं था, तो इसे प्राप्त करना संभव है। इस पर अधिक नीचे।
यह क्यों संभव नहीं है
क्लाइंट होस्टनाम को SSH प्रोटोकॉल के हिस्से के रूप में नहीं भेजता है।
यह होस्टनाम को DNS लुकअप के हिस्से के रूप में भेज सकता है, लेकिन इसे कैश किया जा सकता है, और क्लाइंट से रिसॉल्वर के माध्यम से आधिकारिक सर्वर तक प्रॉक्सी को पार नहीं कर सकता है, और भले ही यह विशिष्ट DNS लुकअप के साथ जुड़ने का कोई मजबूत तरीका नहीं है। विशिष्ट SSH ग्राहक।
कुछ भी फैंसी नहीं है जो आप स्वयं एसएसएच प्रोटोकॉल के साथ कर सकते हैं। आपको क्लाइंट से SSH संस्करण का बैनर देखे बिना भी एक सर्वर चुनना होगा। आपको क्लाइंट को एक बैनर भेजना होगा, इससे पहले कि वह प्रॉक्सी को कुछ भी भेजे। सर्वर से बैनर अलग हो सकते हैं, और आपके पास अनुमान लगाने का कोई मौका नहीं है, जो कि उपयोग करने के लिए सही है।
भले ही यह बैनर अनएन्क्रिप्टेड भेजा गया है, आप इसे संशोधित नहीं कर सकते। उस बैनर के प्रत्येक बिट को कनेक्शन सेटअप के दौरान सत्यापित किया जाएगा, जिससे आप लाइन में थोड़ा सा कनेक्शन विफलता का कारण बनेंगे।
मेरे लिए यह निष्कर्ष बहुत स्पष्ट है, इस कनेक्टिविटी कार्य को करने के लिए ग्राहक पक्ष में कुछ बदलना होगा।
अधिकांश वर्कअराउंड्स SSH ट्रैफ़िक को एक अलग प्रोटोकॉल के अंदर एन्क्रिप्ट कर रहे हैं। स्वयं SSH प्रोटोकॉल के अतिरिक्त जोड़ की कल्पना भी कर सकता है, जिसमें क्लाइंट द्वारा भेजे गए संस्करण बैनर में होस्टनाम शामिल है। यह मौजूदा सीवरों के साथ संगत रह सकता है, क्योंकि बैनर का हिस्सा वर्तमान में एक निशुल्क फॉर्म पहचान क्षेत्र के रूप में निर्दिष्ट किया गया है, और हालांकि ग्राहक आमतौर पर सर्वर से अपने स्वयं के भेजने से पहले संस्करण बैनर का इंतजार करते हैं, प्रोटोकॉल क्लाइंट को अपना बैनर भेजने की अनुमति देता है प्रथम। Ssh क्लाइंट के कुछ हालिया संस्करण (उदाहरण के लिए Ubuntu 14.04 पर एक) सर्वर बैनर की प्रतीक्षा किए बिना बैनर भेजता है।
मुझे किसी भी क्लाइंट का पता नहीं है, जिसने इस बैनर में सर्वर के होस्टनाम को शामिल करने के लिए कदम उठाए हैं। मैंने ऐसी सुविधा जोड़ने के लिए OpenSSH मेलिंग सूची में एक पैच भेजा है । लेकिन यह SSH ट्रैफ़िक पर स्नूपिंग करने वाले किसी को भी होस्टनाम प्रकट नहीं करने की इच्छा के आधार पर अस्वीकार कर दिया गया था। चूंकि एक गुप्त होस्टनाम नाम आधारित प्रॉक्सी के संचालन के साथ मौलिक रूप से असंगत है, इसलिए एसएसएच प्रोटोकॉल के लिए आधिकारिक एसएनआई एक्सटेंशन को जल्द ही देखने की उम्मीद न करें।
एक वास्तविक समाधान
मेरे लिए सबसे अच्छा काम करने वाला समाधान वास्तव में IPv6 का उपयोग करना था।
IPv6 के साथ मेरे पास प्रत्येक सर्वर को एक अलग आईपी पता हो सकता है, इसलिए गेटवे गंतव्य आईपी पते का उपयोग करके पता लगा सकता है कि पैकेट किस सर्वर को भेजा जाए। SSH क्लाइंट कभी-कभी नेटवर्क पर चल रहे हो सकते हैं, जहां IPv6 एड्रेस प्राप्त करने का एकमात्र तरीका टेरेडो का उपयोग करके होगा। टेरेडो को अविश्वसनीय माना जाता है, लेकिन केवल जब कनेक्शन का मूल IPv6 अंत सार्वजनिक टेरेडो रिले का उपयोग कर रहा है। एक बस गेटवे पर एक Teredo रिले डाल सकता है, जहां आप प्रॉक्सी चलाएंगे। Miredo को पांच मिनट से कम समय में रिले के रूप में स्थापित और कॉन्फ़िगर किया जा सकता है।
एक वर्कअराउंड
आप जंप होस्ट / बैस्टियन होस्ट का उपयोग कर सकते हैं। यह दृष्टिकोण उन मामलों के लिए है जहां आप व्यक्तिगत सर्वर के एसएसएच पोर्ट को सीधे सार्वजनिक इंटरनेट पर उजागर नहीं करना चाहते हैं। इसमें SSH के लिए बाहरी रूप से सामना करने वाले IP पते की संख्या को कम करने पर अतिरिक्त लाभ होता है, यही कारण है कि इस परिदृश्य में यह प्रयोग करने योग्य है। तथ्य यह है कि यह सुरक्षा कारणों के लिए सुरक्षा की एक और परत को जोड़ने के लिए एक समाधान है जो आपको अतिरिक्त सुरक्षा की आवश्यकता नहीं होने पर इसका उपयोग करने से नहीं रोकता है।
ssh -o ProxyCommand='ssh -W %h:%p user1@bastion' user2@target
यह काम करने के लिए हैक करने के लिए एक गंदा अगर असली समाधान (IPv6) आपकी पहुंच से बाहर है
जिस हैक के बारे में मैं बताने जा रहा हूं, उसका उपयोग केवल बिल्कुल अंतिम उपाय के रूप में किया जाना चाहिए। इससे पहले कि आप इस हैक का उपयोग करने के बारे में सोचें, मैं दृढ़ता से प्रत्येक सर्वर के लिए एक IPv6 पता प्राप्त करने की सलाह देता हूं, जिसे आप SSH के माध्यम से बाह्य रूप से उपलब्ध होना चाहते हैं। अपने SSH सर्वर तक पहुँचने के लिए अपने प्राथमिक विधि के रूप में IPv6 का उपयोग करें और केवल इस हैक का उपयोग करें जब आपको एक IPH4-only नेटवर्क से SSH क्लाइंट चलाने की आवश्यकता होती है जहाँ आपके पास IPv6 को तैनात करने पर कोई प्रभाव नहीं पड़ता है।
विचार यह है कि क्लाइंट और सर्वर के बीच ट्रैफ़िक को पूरी तरह से वैध एसएसएच ट्रैफ़िक होना चाहिए। लेकिन प्रॉक्सी को केवल होस्टनाम की पहचान करने के लिए पैकेट की धारा के बारे में पर्याप्त समझने की आवश्यकता है। चूंकि SSH होस्टनाम भेजने का एक तरीका परिभाषित नहीं करता है, आप इसके बजाय अन्य प्रोटोकॉल पर विचार कर सकते हैं जो इस तरह की संभावना प्रदान करते हैं।
HTTP और HTTPS दोनों क्लाइंट को सर्वर भेजने से पहले होस्टनाम भेजने की अनुमति देते हैं। अब सवाल यह है कि क्या बाइट्स की एक धारा का निर्माण संभव है जो एसएसएच ट्रैफिक के साथ-साथ HTTP और HTTPS के रूप में मान्य है। HTTP यह बहुत अधिक गैर-स्टार्टर है, लेकिन HTTP संभव है (HTTP की पर्याप्त उदार परिभाषाओं के लिए)।
SSH-2.0-OpenSSH_6.6.1 / HTTP/1.1
$:
Host: example.com
क्या यह आपको SSH या HTTP जैसा लगता है? यह SSH है और पूरी तरह से RFC के अनुरूप है (कुछ द्विआधारी वर्णों को छोड़कर, SF रेंडरिंग द्वारा थोड़ा सा उलझ गया है)।
SSH संस्करण स्ट्रिंग में एक टिप्पणी क्षेत्र शामिल है, जिसमें ऊपर का मान है / HTTP/1.1। Newline के बाद SSH के पास कुछ बाइनरी पैकेट डेटा है। पहला पैकेट MSG_SSH_IGNOREक्लाइंट द्वारा भेजा गया एक संदेश है और सर्वर द्वारा अनदेखा किया जाता है। पेलोड को नजरअंदाज किया जाता है:
:
Host: example.com
यदि एक HTTP प्रॉक्सी पर्याप्त रूप से उदार है जो इसे स्वीकार करता है, तो बाइट्स के उसी क्रम की व्याख्या एक HTTP विधि के रूप में की जाएगी SSH-2.0-OpenSSH_6.6.1और इग्निशन संदेश के प्रारंभ में बाइनरी डेटा को HTTP हेडर नाम के रूप में व्याख्या किया जाएगा।
प्रॉक्सी न तो HTTP विधि या पहले हेडर को समझेगा। लेकिन यह Hostहेडर को समझ सकता है , जो बैकएंड को खोजने के लिए इसकी आवश्यकता है।
इसके लिए प्रॉक्सी को काम करने के लिए इस सिद्धांत पर डिज़ाइन करना होगा कि बैकएंड खोजने के लिए केवल पर्याप्त HTTP को समझना होगा, और बैकएंड मिल जाने के बाद प्रॉक्सी को केवल कच्ची बाइट स्ट्रीम पास करनी होगी और वास्तविक समाप्ति को छोड़ना होगा HTTP कनेक्शन का बैकएंड द्वारा किया जाना है।
यह HTTP प्रॉक्सी के बारे में बहुत सारी धारणाएं बनाने के लिए थोड़ा खिंचाव की तरह लग सकता है। लेकिन अगर आप SSH का समर्थन करने के इरादे से विकसित सॉफ्टवेयर का एक नया टुकड़ा स्थापित करने के लिए तैयार थे, तो HTTP प्रॉक्सी की आवश्यकताएं बहुत खराब नहीं हैं।
मेरे स्वयं के मामले में मुझे यह विधि पहले से ही स्थापित प्रॉक्सी पर काम करने के लिए मिली, जिसमें कोड, कॉन्फ़िगरेशन, या अन्यथा कोई परिवर्तन नहीं था। और यह केवल HTTP और कोई SSH को ध्यान में रखते हुए लिखे गए प्रॉक्सी के लिए था।
अवधारणा क्लाइंट और प्रॉक्सी का प्रमाण । (अस्वीकरण कि प्रॉक्सी मेरे द्वारा संचालित एक सेवा है। इस उपयोग का समर्थन करने के लिए किसी अन्य प्रॉक्सी की पुष्टि होने के बाद लिंक को बदलने के लिए स्वतंत्र महसूस करें।)
इस हैक के Caveats
- इसका उपयोग न करें। वास्तविक समाधान का उपयोग करना बेहतर है, जो कि आईपीवी 6 है।
- यदि प्रॉक्सी HTTP ट्रैफ़िक को समझने का प्रयास करता है, तो यह निश्चित रूप से टूटने वाला है।
- एक संशोधित SSH क्लाइंट पर भरोसा करना अच्छा नहीं है।