एक डिवाइस के लिए रिवर्स SSH: लूपबैक श्रोता या राउटेड VPN?

ऐसे डिवाइस के लिए एक ही प्रबंधन पोर्ट जो केवल बाहर डायल कर सकता है। तीन शर्तें तय करती हैं कि रिवर्स टनल पर्याप्त है या आपको वास्तविक राउटेड पथ चाहिए।

आपका डिवाइस कैरियर NAT के पीछे है, यह बाहर जाने वाले कनेक्शन खोल सकता है, और ऐसा SSH सर्वर चलाता है जहाँ कोई पहुँच नहीं सकता। जो अनुरोध आता है उसे आम तौर पर "इसे VPN दो" के रूप में कहा जाता है, जो कई उत्तरों में से एक है। इसे स्वीकार करने से पहले तय करें कि आपको एक प्रशासनिक TCP पोर्ट चाहिए या पूरे सबनेट तक राउटेड पथ, क्योंकि वे अलग-अलग एक्सपोज़र वाली अलग परियोजनाएँ हैं।

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

चुनाव तय करने वाली तीन शर्तें

किसी भी कॉन्फ़िगरेशन से पहले इन्हें लिख लें। ये सीमित प्रबंधन प्रवेश और नेटवर्क विस्तार के बीच की सीमा हैं, और इन्हें मिला देना ही वह तरीका है जिससे पाँच पंक्तियों की टनल बिना मालिक का सपाट नेटवर्क बन जाती है।

ConditionReverse tunnel fitsSomething else is needed
How many services must be reachable?One, or a small fixed set on loopbackAnything that needs many ports or dynamic discovery
Who connects, and how are they authenticated?Named administrators with their own hub accountsThird parties, or anything needing per-flow audit you do not control
Does the device's own LAN need to be reachable?NoYes, so a routed VPN or a managed platform is the honest answer

तीसरी पंक्ति वह है जिस पर लोग बहस करते हैं। डिवाइस के SSH पोर्ट तक टनल उसके पड़ोसियों को आपके नेटवर्क पर नहीं लाती, और आगे के फ़ॉरवर्ड की श्रृंखला से ऐसा दिखाना नहीं चाहिए। अगर ज़रूरत वास्तव में LAN है, तो यह कहें और इसके बजाय उसे डिज़ाइन करें।

हब पक्ष: सीमित रिले खाता

प्रत्येक डिवाइस को सार्वजनिक कुंजी प्रमाणीकरण के साथ और बिना किसी इंटरैक्टिव सत्र के अपना रिले खाता दें। Match ब्लॉक उस खाते तक सीमित होने से अनुमति छोटी रहती है, और निजी कुंजी उसी डिवाइस पर रहती है जहाँ उसका स्थान है।

Match User relay-dev-7
    AuthenticationMethods publickey
    PubkeyAuthentication yes
    AllowTcpForwarding remote
    PermitListen 127.0.0.1:21022
    GatewayPorts no
    MaxSessions 0
    PermitTTY no
    X11Forwarding no
    AllowAgentForwarding no

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

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

डिवाइस पक्ष: ज़ोर से विफल होने वाली फ़ॉरवर्डिंग

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

ssh -NT \
    -o ExitOnForwardFailure=yes \
    -o ServerAliveInterval=30 \
    -o ServerAliveCountMax=3 \
    -R 127.0.0.1:21022:127.0.0.1:22 \
    [email protected]

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

ExitOnForwardFailure=yes अनुरोधित श्रोता स्थापित न हो पाने पर कमांड को बाहर निकलने पर मजबूर करता है, इसलिए रीस्टार्ट लूप आधे चलते सत्र को छोड़ने के बजाय आपको सच बताता है। यह इस बारे में कुछ नहीं कहता कि स्थानीय SSH सेवा बाद में स्वस्थ है या नहीं, इसलिए इसे प्रोसेस मैनेजर और कभी-कभी वास्तविक कनेक्शन परीक्षण के साथ जोड़ें।

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

हब के माध्यम से प्रशासक पहुँच

हब पर सामान्य खाता रखने वाला प्रशासक उसके माध्यम से फ़ॉरवर्ड किए गए पोर्ट तक कूद सकता है। रिले खाता इसके लिए उपयोग नहीं होता, और उन्हें अलग रखने का अर्थ यही है।

ssh -J [email protected] -o HostKeyAlias=device-7 \
    -p 21022 [email protected]

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

जीवनचक्र का स्वामित्व लें

डिवाइस कमांड को प्रोसेस मैनेजर के अंतर्गत ठीक एक सक्रिय इंस्टेंस और जानबूझकर चुनी गई रीस्टार्ट नीति के साथ चलाएँ। कीपअलाइव विकल्प मृत साथी का पता लगाते हैं; वे बाहर निकल चुकी प्रक्रिया को पुनर्जीवित नहीं करते।

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

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

संबंधित लेख