SSH सर्वर कॉन्फ़िग को सख्त कैसे करें
अंतिम अपडेट:
sshd_config फ़ाइल एक ही टेक्स्ट फ़ाइल में आपके SSH सर्वर की पूरी सुरक्षा स्थिति है — और ज़्यादातर सिस्टम पर यह सुरक्षा के लिए नहीं, संगतता के लिए अनुकूलित स्थिति में आती है। पासवर्ड लॉगिन डिफ़ॉल्ट रूप से चालू है, root तब तक लॉगिन कर सकता है जब तक कुंजी का उपयोग हो, निष्क्रिय सत्र कभी समाप्त नहीं होते, और आपके सर्वर द्वारा दिए जाने वाले एल्गोरिदम वे हैं जो वर्षों पहले स्थापित OpenSSH संस्करण ने तय किए थे। इसे सख्त करना 2021 की चेकलिस्ट की नकल करना नहीं है: एल्गोरिदम हटाए जाते हैं, डिफ़ॉल्ट बदलते हैं, और पाँच साल पहले अनुकरणीय रही कॉन्फ़िग आज कमज़ोर हो सकती है। यह लेख बताता है कि प्रत्येक बदलाव वास्तव में क्या करता है, आपके निर्णयों का क्रम क्यों मायने रखता है, और खुद को बाहर किए बिना नई कॉन्फ़िग का परीक्षण कैसे करें। आप अपनी फ़ाइल की पंक्ति-दर-पंक्ति जाँच SSH सर्वर कॉन्फ़िग ऑडिटर में कर सकते हैं, जो इसे 2026-11-13 दिनांकित बेसलाइन से मिलाता है — पूरी तरह आपके ब्राउज़र में।
डिफ़ॉल्ट एक शुरुआती बिंदु हैं, सख्ती की स्थिति नहीं
OpenSSH ऐसे डिफ़ॉल्ट के साथ आता है जो इसलिए चुने गए हैं ताकि एक नई स्थापना ज़्यादा से ज़्यादा लोगों के लिए काम करे — और यही कारण है कि वे सुरक्षा स्थिति नहीं हैं। sshd_config मैन पेज में दर्ज वर्तमान डिफ़ॉल्ट में PasswordAuthentication yes, PermitRootLogin prohibit-password, MaxAuthTries 6, LoginGraceTime 120 सेकंड और ClientAliveInterval 0 शामिल हैं, जिसका अर्थ है कि निष्क्रिय सत्र कभी समाप्त नहीं होते। इनमें से कोई भी बग नहीं है: प्रत्येक एक जानबूझकर किया गया संगतता का चुनाव है, और सख्ती ऑडिट में प्रत्येक एक निष्कर्ष है।
व्यावहारिक परिणाम यह है कि जिस सर्वर को कभी किसी ने सख्त नहीं किया, वह अब भी पासवर्ड अनुमान से पहुँचा जा सकता है, अब भी चुराई गई कुंजी से root लॉगिन स्वीकार करता है, और अब भी छोड़े गए सत्रों को अनिश्चित काल तक खुला रखता है। डिफ़ॉल्ट समय के साथ बदलते भी हैं — OpenSSH 10.6 जो लाता है वह OpenSSH 7 वाला नहीं है — इसलिए "मैंने कभी कुछ नहीं बदला" कोई तटस्थ कथन नहीं है। इसका अर्थ है कि आपकी सुरक्षा स्थिति वही है जो संयोग से स्थापित संस्करण ने तय की थी, और यह जानने का एकमात्र तरीका फ़ाइल को पढ़ना है। ऑडिट का पहला काम यही है: अदृश्य डिफ़ॉल्ट को दृश्य बनाना, क्योंकि फ़ाइल में न दिखने वाला निर्देश भी लागू रहता है।
पासवर्ड बंद करना पोर्ट बदलने से हमेशा बेहतर है
sshd_config में सबसे प्रभावी एकल बदलाव PasswordAuthentication no और PubkeyAuthentication yes का संयोजन है: इस क्षण से, अनुमान लगाया गया, लीक हुआ या फ़िशिंग से चुराया गया कोई भी पासवर्ड सत्र नहीं खोल सकता, क्योंकि डेमन अब उस प्रकार का प्रमाण स्वीकार ही नहीं करता। कुंजी प्रमाणीकरण हमले को "किसी इंसान द्वारा चुने गए रहस्य का अनुमान लगाने" से बदलकर "ऐसी निजी कुंजी फ़ाइल चुराने" में बदल देता है जो कभी नेटवर्क पार नहीं करती, और इसीलिए Mozilla सहित हर सख्ती बेसलाइन यहीं से शुरू होती है। अगर इस लेख से एक ही बात ले जाएँ, तो वह यही हो: एक कुंजी युग्म बनाएँ (SSH कुंजी सूट और साथी लेख SSH कुंजियाँ समझाई गईं देखें), सार्वजनिक कुंजी स्थापित करें, सत्यापित करें कि आप उससे लॉगिन कर सकते हैं, और तभी पासवर्ड बंद करें।
इसके विपरीत, पोर्ट को 22 से किसी कम ज्ञात पोर्ट पर बदलना सख्ती नहीं है — यह छिपाव है। यह आपके लॉग में शोर कम करता है, क्योंकि इंटरनेट-व्यापी अधिकांश स्कैनर केवल पोर्ट 22 पर दस्तक देते हैं, लेकिन यह किसी भी हमलावर को नहीं रोकता जो स्कैन करने की जहमत उठाए: एक पोर्ट स्कैन कुछ ही सेकंड में डेमन को ढूँढ लेता है, और उसके पीछे का डेमन ठीक उतना ही मज़बूत है जितनी उसकी कॉन्फ़िग। इसलिए ऑडिटर 22 से भिन्न पोर्ट को केवल जानकारी के रूप में मानता है, कभी भी अंक दिए जाने वाले सुधार के रूप में नहीं। स्विच पलटने से पहले जानने लायक एक जाल है: PAM का उपयोग करने वाले सिस्टम पर अकेला PasswordAuthentication no पर्याप्त नहीं है — कीबोर्ड-इंटरैक्टिव प्रमाणीकरण अब भी PAM को पासवर्ड स्वीकार करने दे सकता है, इसलिए /etc/pam.d/sshd में PAM स्टैक को भी पासवर्ड अस्वीकार करने चाहिए। Mozilla के दिशानिर्देश इसे स्पष्ट रूप से कहते हैं, और यह बदलाव का सबसे अधिक छूटने वाला दूसरा आधा हिस्सा है।
root लॉगिन: prohibit-password वास्तव में क्या अनुमति देता है
PermitRootLogin के चार मान हैं, और उनके बीच का अंतर ऑडिट ट्रेल होने या न होने का अंतर है। डिफ़ॉल्ट मान prohibit-password root को लॉगिन करने देता है — बस पासवर्ड से नहीं। चुराई गई root कुंजी फिर भी बिना रुकावट अंदर आ जाती है, और एक बार सत्र root बन जाए तो लॉग में कुछ भी एक व्यवस्थापक को दूसरे से अलग नहीं करता। Mozilla की Modern प्रोफ़ाइल इसे No पर सेट करती है, और यही सख्त उत्तर है: root कभी भी लॉगिन खाता नहीं होना चाहिए। नाम वाले उपयोगकर्ता के रूप में लॉगिन करें और sudo का उपयोग करें; तब प्रत्येक विशेषाधिकार प्राप्त क्रिया किसी व्यक्ति से जोड़ी जा सकती है।
बीच वाले मान किसी कारण से मौजूद हैं, और उन्हें डरने के बजाय जानना चाहिए। forced-commands-only root लॉगिन तभी अनुमति देता है जब प्रस्तुत कुंजी authorized_keys में एक ही कमांड तक सीमित हो — वह पैटर्न जिसका उपयोग बैकअप और निगरानी स्क्रिप्ट करते हैं — और यह स्वचालन के लिए एक वैध, जानबूझकर किया गया चुनाव है। जो वैध नहीं है वह yes है, जो root को पासवर्ड से लॉगिन करने देता है और किसी भी ऑडिट में त्रुटि है। व्यावहारिक नियम: अगर कोई इंसान root के रूप में लॉगिन करता है, तो कॉन्फ़िग गलत है; अगर कोई स्क्रिप्ट करती है, तो कुंजी को एक कमांड तक सीमित करें और टिप्पणी में यह लिखें, क्योंकि फ़ाइल पढ़ने वाला अगला व्यक्ति अन्यथा इसे "ठीक" कर देगा।
एल्गोरिदम का हटाया जाना एक चलता हुआ लक्ष्य है
आपकी कॉन्फ़िग में एल्गोरिदम की समाप्ति तिथि होती है, और यह आपके विचार से कम है। OpenSSH 10.0 (2025-04-09 को जारी) ने DSA (ssh-dss) समर्थन को पूरी तरह हटा दिया, परिमित-क्षेत्र Diffie-Hellman को सर्वर के डिफ़ॉल्ट कुंजी विनिमय से हटा दिया, और mlkem768x25519-sha256 — एक पोस्ट-क्वांटम हाइब्रिड — को डिफ़ॉल्ट कुंजी सहमति बना दिया। 2021 के ब्लॉग पोस्ट से कॉपी की गई कॉन्फ़िग में अब भी diffie-hellman-group1-sha1, 3des-cbc, arcfour या hmac-md5 सूचीबद्ध हो सकते हैं, जो आधुनिक ऑडिट में सभी त्रुटियाँ हैं, और जिनमें से कुछ को स्थापित डेमन अब समर्थन भी नहीं करता। कॉन्फ़िग नहीं बदली; दुनिया बदल गई।
इसीलिए सख्ती बेसलाइन पर तारीख होनी चाहिए, और फिर से जाँचना काम का हिस्सा है, बाद का विचार नहीं। Mozilla की Modern प्रोफ़ाइल — curve25519 कुंजी विनिमय, chacha20-poly1305 और AES-GCM सिफर, SHA-2 एन्क्रिप्ट-देन-MAC — संदर्भ है, लेकिन यह उन पोस्ट-क्वांटम कुंजी विनिमयों से पहले की है जिन्हें OpenSSH 10.0 ने डिफ़ॉल्ट बनाया, इसलिए 2026 का ऑडिट उनके साथ-साथ mlkem768x25519-sha256 और sntrup761x25519-sha512 को भी स्वीकार करता है। आपको अद्यतन रखने वाली आदत सस्ती है: साल में एक या दो बार, सर्वर पर ssh -Q kex, ssh -Q cipher और ssh -Q mac चलाएँ ताकि देखें कि स्थापित संस्करण वास्तव में क्या देता है, इसकी तुलना वर्तमान Mozilla दिशानिर्देशों से करें, और उसी फ़ाइल पर ऑडिटर को फिर से चलाएँ। 2021 का साफ़ स्कोर एक ऐतिहासिक दस्तावेज़ है, वर्तमान नहीं।
Match ब्लॉक और Include: दो तरीके जिनसे एक साफ़ ऑडिट झूठ बोलता है
कॉन्फ़िग फ़ाइल सेटिंग्स की सपाट सूची नहीं है — यह सशर्त शाखाओं वाला एक प्रोग्राम है, और दो विशेषताएँ एक ऐसी फ़ाइल को, जो सख्त पढ़ी जाती है, ऐसे व्यवहार करा सकती हैं जैसे वह न हो। पहली है Match ब्लॉक: Match User, Match Group या Match Address ब्लॉक के अंदर के निर्देश तभी लागू होते हैं जब मानदंड पूरे हों, और मैन पेज स्पष्ट है: यदि कोई कीवर्ड कई संतुष्ट Match ब्लॉकों में आता है, तो केवल पहला उदाहरण लागू होता है। एक वैश्विक PasswordAuthentication no जिसके बाद एक Match ब्लॉक आता है जो किसी एक समूह के लिए चुपचाप पासवर्ड फिर से चालू कर देता है, एक वास्तविक कॉन्फ़िग है, और ठीक वही चीज़ है जिसे पंक्ति-दर-पंक्ति पढ़ना चूक जाता है। Match ब्लॉक के अंदर के निष्कर्ष सशर्त होते हैं, कभी वैश्विक नहीं, और कोई भी ईमानदार ऑडिट उन्हें उसी तरह सीमित करता है।
दूसरा है Include। आधुनिक वितरण sshd_config को कई फ़ाइलों में बाँटते हैं — /etc/ssh/sshd_config.d/*.conf सामान्य पैटर्न है — और एक Include निर्देश उन फ़ाइलों को, शब्दकोशीय क्रम में, उस स्थान पर खींच लाता है जहाँ वह आता है। क्योंकि पहले प्राप्त मान की जीत होती है, शामिल फ़ाइल में सेट किया गया निर्देश मुख्य फ़ाइल में आगे आने वाले उसी निर्देश को छिपा देता है: जो पंक्ति आप पढ़ते हैं वह वह पंक्ति नहीं है जो शासन करती है। ब्राउज़र में चलने वाला ऑडिटर Include का अनुसरण नहीं कर सकता — फ़ाइलें आपकी मशीन पर नहीं हैं — इसलिए वह उन्हें "अनुसरण नहीं किया गया" के रूप में चिह्नित करता है और पथ सूचीबद्ध करता है। जब आप ऑडिट करें, तो एक फ़ाइल नहीं, पूरी निर्देशिका का ऑडिट करें, और याद रखें कि दोहराया गया निर्देश कोई अनदेखा करने योग्य टाइपो नहीं है: पहला जीतता है और दूसरा मृत पाठ है जो फ़ाइल संपादित करने वाले अगले व्यक्ति को भ्रमित करेगा।
सुरक्षित रोलआउट: दरवाज़ा बंद करने से पहले परीक्षण करें
sshd_config के हर बदलाव में वही जोखिम होता है: एक टाइपो डेमन को पुनरारंभ करने से रोक सकता है, और एक सही-परंतु-गलत सेटिंग आपको ही रोक सकती है। दोनों से बचने वाला रोलआउट छोटा और गैर-परक्राम्य है। पहले, चल रही सेवा को छूने से पहले sshd -t से सिंटैक्स जाँचें — यह फ़ाइल को पार्स करता है और कुछ भी शुरू किए बिना त्रुटियों की रिपोर्ट करता है। फिर डेमन को पुनरारंभ या पुनः लोड करें, और तभी परीक्षण करें। कॉन्फ़िग संपादित करते हुए अपना एकमात्र सत्र उसी साँस में कभी बंद न करें।
परीक्षण स्वयं ही अनुशासन है: अपना मौजूदा सत्र खुला रखें, दूसरा सत्र खोलें, और नए नियम लागू होने के साथ नए सिरे से लॉगिन करें। यदि दूसरा लॉगिन काम करता है, तो बदलाव सुरक्षित है और पहला सत्र बंद किया जा सकता है; यदि नहीं, तो खुला सत्र आपकी वापसी का रास्ता है, और आप फ़ाइल को वापस करके पुनः लोड कर सकते हैं। यही कारण है कि जिस सर्वर तक आप भौतिक रूप से नहीं पहुँच सकते, उस पर बदलाव एक बार में एक ही करने चाहिए — एक ही संपादन में टूटी कुंजी फ़ाइल और अक्षम पासवर्ड विधि कोई वापसी नहीं छोड़ते। ऑडिटर आपकी फ़ाइल का एक सख्त संस्करण शुरुआती बिंदु के रूप में बना सकता है, लेकिन यह एक मसौदा है जिसकी Match ब्लॉक-दर-Match ब्लॉक समीक्षा करनी है और sshd -t से परीक्षण करना है — कभी भी बिना समीक्षा के डालने वाली फ़ाइल नहीं।