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 ले विशिष्ट सूची आवश्यकतासँग मिल्दा गन्तव्य होस्ट र पोर्ट जोडीहरू सीमित गर्न सक्छ। यो प्रत्येक निजी नेटवर्कमा होस्टनाम-समाधानलाई ध्यान दिने सामान्य प्रतिबन्ध होइन। फराकिलो ठेगाना प्रतिबन्धका लागि उपयुक्त होस्ट नेटवर्क नीति आवश्यक हुन सक्छ।

खाता, कुञ्जी र समाविष्ट सर्भर सेटिङहरूले फर्वार्डिङलाई थप सीमित गर्न सक्छन्। अन्यत्रको व्यापक फर्वार्डिङ प्रतिबन्धले यो अंशले अनुमति दिने देखिने क्षमता हटाउन सक्छ।

पुनःप्राप्ति मार्गसहित सामान्य सर्भर प्रशासन प्रक्रिया प्रयोग गर्नुहोस्, त्यसपछि अनुमत र अस्वीकृत क्षमताहरूको छुट्टाछुट्टै मूल्याङ्कन गर्नुहोस्। इच्छित परिणाम स्पष्ट फर्वार्डिङ अनुमतिहरू हुन्, दुर्घटनावश खुला छोडिएको इन्टरएक्टिभ लगइन वा आफ्नै सीमाले निष्क्रिय बनाइएको प्रोक्सी होइन।