SSH प्रॉक्सी खाता shell के बिना काम कर सकता है

लुभावनी सेटिंग AllowTcpForwarding no है। दुर्भाग्यवश, यह वह फ़ॉरवर्डिंग भी बंद कर देती है जिसकी स्थानीय SSH SOCKS प्रॉक्सी को ज़रूरत होती है। गतिशील फ़ॉरवर्डिंग सर्वर नीति के इर्द-गिर्द कोई खिड़की नहीं है।

समर्पित खाते के लिए OpenSSH कई क्षमताएँ अलग करता है। एक नीति-अंश shell और सबसिस्टम सत्रों को रोकते हुए स्थानीय फ़ॉरवर्डिंग की अनुमति दे सकता है:

Match User proxyuser
    AllowTcpForwarding local
    MaxSessions 0
    PermitTTY no
    X11Forwarding no
    AllowAgentForwarding no

सर्वर मैनुअल MaxSessions 0 को shell, लॉगिन और सबसिस्टम सत्रों को रोकने वाला तथा फ़ॉरवर्डिंग की अनुमति देने वाला बताता है। इसे किसी मौजूदा प्रमाणित खाते में समेकित करें; यह पूर्ण SSH सुरक्षा कॉन्फ़िगरेशन नहीं है।

केवल फ़ॉरवर्डिंग का अर्थ केवल SOCKS नहीं

एक स्थिर स्थानीय फ़ॉरवर्ड और एक SOCKS अनुरोध अंततः सर्वर से उसी प्रकार का गंतव्य कनेक्शन माँग सकते हैं। स्थानीय फ़ॉरवर्डिंग की अनुमति यह सुनिश्चित नहीं करती कि क्लाइंट ने कोई विशिष्ट SOCKS इंटरफ़ेस इस्तेमाल किया। खाते को केवल-SOCKS उपयोग लागू करने वाला न बताएँ।

PermitOpen विशिष्ट सूची आवश्यकता से मेल खाने पर गंतव्य होस्ट और पोर्ट युग्म को सीमित कर सकता है। यह हर निजी नेटवर्क पर होस्टनाम-विश्लेषण को ध्यान में रखने वाला सामान्य प्रतिबंध नहीं है। व्यापक पता प्रतिबंधों के लिए उपयुक्त होस्ट नेटवर्क नीति की आवश्यकता हो सकती है।

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

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