MaxSessions, MaxStartups या नामांकन: कौन सी SSH सीमा चुनें

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

हर विकल्प वास्तव में क्या गिनता है

MaxSessions एक प्रमाणित नेटवर्क कनेक्शन द्वारा ले जाए जाने वाले खुले सत्रों की संख्या सीमित करता है। यहाँ सत्र का अर्थ शेल, exec अनुरोध, SFTP जैसी उपप्रणाली, या एक SSH ट्रांसपोर्ट के भीतर मल्टीप्लेक्स किया गया समान चैनल है। दूसरी ssh कॉल दूसरा ट्रांसपोर्ट खोलती है, फिर से प्रमाणित होती है और अपनी अनुमति पाती है। पहले कनेक्शन की सत्र संख्या इसके लिए अप्रासंगिक है।

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

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

MaxSessions कहाँ कोटा रहना बंद करता है

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

फ़ॉरवर्डिंग एक अलग आश्चर्य है। TCP फ़ॉरवर्डिंग को सत्र चैनल की आवश्यकता नहीं होती, इसलिए MaxSessions 0 शेल और उपप्रणालियों को प्रतिबंधित कर सकता है और फिर भी -L और -R टनल की अनुमति दे सकता है। जो सेवा केवल फ़ॉरवर्ड करती है और सत्र संख्या को अपना टनल कोटा मानती है, वह कुछ भी नहीं मापती। यह व्यवहार OpenSSH सर्वर कॉन्फ़िगरेशन संदर्भ में प्रलेखित है, और किसी विकल्प नाम के आसपास डिज़ाइन करने से पहले इसे पढ़ना उचित है।

आप जिस फ़ाइल को लोड हुआ मानते हैं उसके बजाय प्रभावी कॉन्फ़िगरेशन डंप करें। इन्क्लूड और drop-in निर्देशिकाओं का अर्थ अक्सर यह होता है कि प्रभावी मान वह नहीं है जिसे आपने संपादित किया।

MaxStartups ग्राहक की नहीं, डेमॉन की रक्षा करता है

MaxStartups का तीन-भाग रूप बताता है कि डेमॉन नए कनेक्शनों का कुछ प्रतिशत गिराना शुरू करने से पहले कितने अप्रमाणित कनेक्शन हो सकते हैं। इसका डिफ़ॉल्ट रूप इसलिए है क्योंकि अप्रमाणित SSH कनेक्शन खोलना सस्ता और बनाए रखना महंगा है। यह सर्वर के लिए संसाधन-सुरक्षा नियंत्रण है, और यह एक साथ सभी पर लागू होता है।

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

जब लॉगिन झुंड में अस्वीकार होते हैं, तो किसी भी विकल्प को छूने से पहले डेमॉन लॉग में प्रमाणीकरण-पूर्व संदेश देखें। संदेश बताता है कि कौन सा रक्षक सक्रिय हुआ, और रक्षक आपस में बदले नहीं जा सकते।

प्रति-उपयोगकर्ता स्लॉट को साझा स्थिति चाहिए

सच्ची एक-सक्रिय-ट्रांसपोर्ट नीति को sshd के बाहर कहीं रखे गए आरक्षण की आवश्यकता होती है। प्रवेश चरण को खाते का स्लॉट परमाणु रूप से दावा करना होगा, कनेक्शन बंद होने पर उसे मुक्त करना होगा, क्लाइंट बंद किए बिना गायब होने पर उसे समाप्त करना होगा, और तय करना होगा कि नया प्रयास अस्वीकार होता है या पुराने को बदलता है। वह अंतिम निर्णय उत्पाद निर्णय है, तकनीकी ब्यौरा नहीं, क्योंकि सक्रिय टनल बदलने से किसी का कनेक्शन टूटता है।

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

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

दो वास्तविक कनेक्शनों से नीति जाँचें

नीति लिखने से पहले स्वीकृति परीक्षण कमांड के रूप में लिखें। पाँच मामले हैं: पहला सक्रिय रहते दूसरा ट्रांसपोर्ट खुलना, एक ट्रांसपोर्ट के भीतर कई चैनल, केवल पोर्ट फ़ॉरवर्ड करने वाला क्लाइंट, लिंक टूटने के बाद पुनः कनेक्शन, और वही खाता दूसरे गेटवे पर पहुँचना।

पहले प्रभावी सीमाएँ पढ़ें, फिर वे कनेक्शन खोलें जिन्हें नीति को अस्वीकार करना चाहिए। उस परीक्षण के दोनों आधे महत्वपूर्ण हैं, और कोई भी दूसरे का विकल्प नहीं है।

sshd -T | grep -iE "maxsessions|maxstartups|allowtcpforwarding|permitopen"
ss -tn state established '( sport = :22 )' | head
ssh -N -L 8080:127.0.0.1:80 [email protected]

दो टर्मिनलों में टनल कमांड दो बार चलाएँ और पोर्ट 22 पर स्थापित कनेक्शन गिनें। यदि आपकी नीति एक सक्रिय ट्रांसपोर्ट का दावा करती है और दोनों ट्रैफ़िक ले जाते हैं, तो नीति प्रवर्तन नहीं, दस्तावेज़ है। उस अंतराल को प्रवेश परत में ठीक करें, MaxSessions घटाकर यह आशा करके नहीं कि दूसरा ट्रांसपोर्ट इसे नोटिस करेगा।