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 घटाएर दोस्रो ट्रान्सपोर्टले याद गर्ला भन्ने आशा गरेर होइन।