sshd वैलिडेटर
SSH सुरक्षा नियंत्रण जाँचें- ✓कोई गंभीर समस्या नहीं मिली
परिचय
sshd वैलिडेटर चिपकाया गया sshd_config पढ़ता है और पाँच नियंत्रण जाँचता है जो कमज़ोर SSH स्थिति के सबसे आम कारण हैं: रूट लॉगिन, खाली पासवर्ड, पासवर्ड प्रमाणीकरण, प्रमाणीकरण प्रयास और X11 फ़ॉरवर्डिंग।
लक्ष्य SSH का कोई विचारधारा थोपना नहीं है — ऐसी सेटिंग्स उजागर करना है जो मिलकर तय करती हैं कि हमलावर brute force कर पाएगा या कोई वैध उपयोगकर्ता खुद को बाहर बंद कर लेगा।
उद्देश्य
- PermitRootLogin के उन मानों का पता लगाना जो सीधा रूट लॉगिन देते हैं।
- PermitEmptyPasswords सक्षम होने का पता लगाना, जो बिना पासवर्ड वाले खातों की अनुमति देता है।
- PasswordAuthentication सक्षम रहने पर चेतावनी देना और कुंजी-आधारित पहुँच की अनुशंसा करना।
- MaxAuthTries 4 से अधिक और बिना बताई ज़रूरत के X11Forwarding सक्षम होने को चिह्नित करना।
इनपुट
- /etc/ssh/sshd_config (या sshd -T आउटपुट) की चिपकाई गई सामग्री।
- टिप्पणी और खाली पंक्तियाँ अनदेखी होती हैं; हर कुंजी का पहला मान जीतता है।
यह कैसे काम करता है
उपकरण हर पंक्ति को कुंजी और मान में विभाजित करता है (केस-असंवेदनशील), हर कुंजी की पहली उपस्थिति रखता है — जैसे sshd अपनी डिफ़ॉल्ट फ़ाइल लागू करता है।
फिर हर प्रासंगिक कुंजी की तुलना हार्डन किए गए अपेक्षा से होती है: permitrootlogin no होना चाहिए, permitemptypasswords no होना चाहिए, passwordauthentication no होना चाहिए, maxauthtries 4 या उससे कम होना चाहिए, और x11forwarding no होना चाहिए।
रूट लॉगिन और खाली पासवर्ड उच्च गंभीरता के हैं क्योंकि वे दूरस्थ समझौते की दो मुख्य बाधाएँ हटाते हैं। शेष नियंत्रण चेतावनी हैं क्योंकि उनका आदर्श मान आपके वातावरण पर निर्भर करता है।
परीक्षण योग्य उदाहरण
आज़माएँ — विश्लेषण आपके ब्राउज़र में स्थानीय रूप से चलता है।
उदाहरण
PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes PermitEmptyPasswords no MaxAuthTries 4 X11Forwarding no
अपेक्षित आउटपुट
PermitRootLogin no — OK। PermitEmptyPasswords no — OK। PasswordAuthentication no — OK। MaxAuthTries 4 — OK। X11Forwarding no — OK। परिणाम: कोई गंभीर समस्या नहीं मिली।
आउटपुट पढ़ना
- उच्च निष्कर्ष का मतलब है कि सेटिंग सिस्टम को सक्रिय रूप से कमज़ोर करती है; अपने पहुँच पथ (sudo-क्षम उपयोगकर्ता और काम करती कुंजी) की पुष्टि के बाद उसे ठीक करें।
- चेतावनी एक अनुशंसा है — उदाहरण के लिए, पासवर्ड प्रमाणीकरण बंद करना तभी सुरक्षित है जब कुंजी-आधारित लॉगिन सत्यापित हो।
- sshd रीलोड करने से पहले हमेशा दूसरी SSH सत्र खुली रखकर परीक्षण करें: systemctl reload ssh (या service ssh reload)।
जोखिम
- बिना कुंजी कॉन्फ़िगर किए पासवर्ड प्रमाणीकरण बंद करना आपको सर्वर से बाहर कर सकता है।
- PermitRootLogin yes मशीन के सबसे मूल्यवान खाते पर लक्षित brute force को निमंत्रण देता है।
- दूसरी सत्र खुली रखे बिना sshd_config बदलना रिमोट पहुँच खोने का क्लासिक तरीका है।
सीमाएँ
- उपकरण केवल चिपकाया गया टेक्स्ट पढ़ता है; यह आपकी वास्तविक कॉन्फ़िगरेशन फ़ाइल नहीं पढ़ता।
- यह कुछ नियंत्रण जाँचता है, पूर्ण SSH ऑडिट नहीं।
- यह गलत प्रमाणीकरण विधियाँ, कमज़ोर host keys या SSH agent समस्याएँ नहीं पहचान सकता।
आधिकारिक संदर्भ
FAQ
क्या पासवर्ड प्रमाणीकरण बंद करना हमेशा सही है?
इंटरनेट-सामने वाले सर्वरों के लिए लगभग हमेशा — लेकिन केवल दूसरी सत्र से कुंजी लॉगिन सत्यापित करने के बाद। कुछ प्रबंधित वातावरणों में bastion के लिए पासवर्ड auth रखना आवश्यक हो सकता है।
MaxAuthTries का सुरक्षित मान क्या है?
CIS 4 या उससे कम की अनुशंसा करता है। कम मान brute force धीमा करते हैं लेकिन गलत कॉन्फ़िगर किए agent वाले वैध उपयोगकर्ताओं को परेशान कर सकते हैं।
क्या यह मेरी वास्तविक sshd_config जाँचता है?
नहीं — केवल वही टेक्स्ट जो आप चिपकाते हैं। असली स्रोत /etc/ssh/sshd_config और /etc/ssh/sshd_config.d/ के अंतर्गत फ़ाइलें हैं, जिन्हें आप sshd -T से जोड़ सकते हैं।