रिवर्स SSH प्रॉक्सी लिसनर केवल सर्वर पर ही क्यों पहुँच योग्य होता है
प्रॉक्सी प्रोटोकॉल या क्रेडेंशियल बदलने से पहले रिमोट लिसनर का bind पता और GatewayPorts मोड जाँचें।
रिमोट फ़ॉरवर्ड SSH सर्वर से काम कर सकता है, पर किसी दूसरी मशीन से आने वाले कनेक्शन अस्वीकार कर सकता है, क्योंकि यह केवल loopback पर सुनता है। पहले वास्तविक सुनने का पता जाँचें।
सर्वर की ओर GatewayPorts | रिमोट-फ़ॉरवर्ड bind |
|---|---|
no, डिफ़ॉल्ट | लिसनर को loopback तक सीमित करता है |
yes | wildcard bind को बाध्य करता है |
clientspecified | क्लाइंट को विशिष्ट bind पता माँगने देता है |
एक नियंत्रित इंटरफ़ेस के लिए इच्छित लिसनर के लिए, सर्वर यह उपयोग कर सकता है:
GatewayPorts clientspecifiedफिर क्लाइंट अपने -R विनिर्देश में उपयुक्त पता माँगता है। वह पता रिमोट मशीन पर मौजूद होना चाहिए, और अन्य फ़ॉरवर्डिंग प्रतिबंध अभी भी लागू हैं। क्लाइंट-साइड -g इस दिशा के लिए विनिमेय नियंत्रण नहीं है।
तीन अनुमतियाँ अलग रहती हैं: फ़ॉरवर्ड बनाने की SSH अनुमति, उसके लिसनर तक नेटवर्क पहुँच, और HTTP या SOCKS सेवा की अपनी पहुँच नीति। SSH लॉगिन सुरंग बनाने वाले को प्रमाणित करता है; यह साझा लिसनर के हर बाद के कॉलर को प्रमाणित नहीं करता और SOCKS पासवर्ड चुनौती नहीं जोड़ता।
अगर कोई रिमोट कॉलर अब भी कनेक्ट नहीं कर पाता, तो bind पता, सर्वर के फ़ॉरवर्डिंग प्रतिबंध और फ़ायरवॉल पथ इसी क्रम में जाँचें। TCP के लिसनर तक पहुँचने के बाद, विफल प्रॉक्सी हैंडशेक बाद की समस्या है।