VPS पर SSH को सुरक्षित कैसे करें: स्टेप-बाय-स्टेप गाइड

SSH को सुरक्षित करना सबसे पहली प्राथमिकता क्यों है

SSH वह माध्यम है जिससे आप अपने सर्वर को नियंत्रित करते हैं, इसलिए यह वह ताला है जिसे हर हमलावर सबसे पहले तोड़ने की कोशिश करता है। जैसे ही कोई VPS ऑनलाइन आता है, स्कैनर्स port 22 पर usernames और passwords का अनुमान लगाना शुरू कर देते हैं। आप कुछ ही मिनटों में अपने logs में इसे होते हुए देख सकते हैं। SSH को सुरक्षित करने का अर्थ है उन चीजों को हटाना जिनका वे अनुमान लगा सकते हैं: password login को पूरी तरह बंद करें, root login को अक्षम करें, और केवल cryptographic keys को ही अनुमति दें। एक बार जब आप ऐसा कर लेते हैं, तो लगातार अनुमान लगाने के प्रयास सफल नहीं हो सकते, क्योंकि खोजने के लिए कोई password ही नहीं होता।

यह मानकर चला गया है कि आपका SSH पहले से काम कर रहा है। यदि आप login कर सकते हैं, तो आप इसे सुरक्षित भी कर सकते हैं। इन चरणों का क्रमवार पालन करें और अपना वर्तमान session खुला रखें जब तक कि नया session काम न करने लगे, ताकि किसी गलती के कारण आप खुद को सर्वर से बाहर न कर दें।

चरण 1: सुनिश्चित करें कि key authentication पहले काम कर रहा है

Key authentication पासवर्ड की जगह एक key pair का उपयोग करता है: एक private key जो आपके कंप्यूटर पर रहती है और एक public key जिसे आप सर्वर पर रखते हैं। सर्वर यह पुष्टि करता है कि आपके पास private key है, बिना उसे आपकी मशीन से बाहर भेजे। पासवर्ड डिसेबल करने से पहले, यह सुनिश्चित कर लें कि keys काम कर रही हैं, अन्यथा आप खुद को सर्वर से बाहर लॉक कर लेंगे।

अपने कंप्यूटर पर, यदि आपके पास key नहीं है तो एक key बनाएँ:

ssh-keygen -t ed25519

Public key के हिस्से को सर्वर पर कॉपी करें:

ssh-copy-id user@your-server

इसके बाद एक नया SSH session खोलें। यदि यह बिना पासवर्ड मांगे आपको login करने देता है, तो आपकी key काम कर रही है और आप पासवर्ड बंद करने के लिए सुरक्षित हैं। यदि यह आपको Permission denied (publickey) के साथ रोकता है, तो वह एक error पांच अलग-अलग समस्याओं को छुपाता है, और कुछ भी बदलने से पहले ssh -v का output आपको बताएगा कि आपके साथ कौन सी समस्या है। यदि keys आपके लिए नई हैं, या आप एक से अधिक कंप्यूटर का उपयोग करते हैं, तो SSH key management basics पूरा मॉडल समझाता है: प्रति डिवाइस एक key, sshd द्वारा मांगी जाने वाली permissions, और लैपटॉप खो जाने पर key को कैसे revoke करें।

चरण 2: drop-in फ़ाइल के साथ sshd को सुरक्षित (harden) करना

सीधे /etc/ssh/sshd_config को एडिट न करें। Ubuntu 24.04, /etc/ssh/sshd_config.d/ से drop-in फ़ाइलों को पढ़ता है। वहाँ एक छोटी फ़ाइल रखना अधिक व्यवस्थित है, यह पैकेज अपग्रेड के दौरान सुरक्षित रहती है, और यदि कोई समस्या हो तो इसे हटाना आसान है। फ़ाइल का नाम महत्वपूर्ण है: sshd प्रत्येक सेटिंग के लिए सबसे पहले पढ़ी गई वैल्यू को ही रखता है। Ubuntu क्लाउड इमेज इस डायरेक्टरी में 50-cloud-init.conf के साथ PasswordAuthentication yes प्रदान करती हैं। अपनी फ़ाइल का नाम 00- रखें ताकि यह वर्णानुक्रम में पहले आए और प्रभावी हो; 99- नाम वाली फ़ाइल चुपचाप अनदेखी कर दी जाएगी। एक फ़ाइल बनाएँ:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

इसमें यह सामग्री डालें:

# Key-only login: no passwords to guess.
PasswordAuthentication no
KbdInteractiveAuthentication no

# No direct root login. Log in as your user, then use sudo.
PermitRootLogin no

प्रत्येक लाइन एक सुरक्षा द्वार बंद करती है। PasswordAuthentication no सबसे महत्वपूर्ण है: पासवर्ड बंद होने पर, brute-force हमले के लिए कुछ भी शेष नहीं रहता। KbdInteractiveAuthentication no पासवर्ड-आधारित प्रवेश के दूसरे रास्ते को बंद कर देता है। PermitRootLogin no का अर्थ है कि हमलावर को न केवल आपका यूजरनेम पता होना चाहिए, बल्कि आपके पास key भी होनी चाहिए। यह केवल उस root अकाउंट को लक्षित करने से रोकता है जो हर सर्वर पर मौजूद होता है।

चरण 3: कॉन्फ़िगरेशन का परीक्षण करें, फिर रिलोड करें

लागू करने से पहले कॉन्फ़िगरेशन में गलतियों की जाँच करें, ताकि कोई टाइपिंग त्रुटि सर्विस को बाधित न करे:

sudo sshd -t

यदि यह कुछ भी प्रिंट नहीं करता है, तो कॉन्फ़िगरेशन मान्य है। SSH को रिलोड करें:

sudo systemctl reload ssh

फिर उन सेटिंग्स की जाँच करें जिनका sshd वास्तव में उपयोग कर रहा है, ताकि आप किसी ऐसी ड्रॉप-इन फ़ाइल को पकड़ सकें जो किसी अन्य फ़ाइल के कारण प्रभावी नहीं हो पाई:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

दोनों में no लिखा होना चाहिए। अब, अपने वर्तमान सत्र को बंद किए बिना, किसी अन्य टर्मिनल से एक बिल्कुल नया सत्र खोलें। यदि यह आपको आपकी की (key) के साथ लॉग इन कर देता है, तो आपका काम पूरा हो गया है। यदि कुछ भी गलत है, तो आपका पहला सत्र उसे ठीक करने के लिए अभी भी खुला है। यह ओवरलैप एक सुरक्षा कवच है, इसलिए इसे कभी न छोड़ें।

Step 4: वैकल्पिक non-standard port

SSH को port 22 से हटाकर 2222 जैसे किसी अन्य port पर ले जाने से सुरक्षा में कोई वास्तविक सुधार नहीं होता है, क्योंकि एक दृढ़ हमलावर सभी ports को scan कर लेता है। यह केवल log में होने वाले शोर (noise) को कम करता है, क्योंकि अधिकांश automated scanners केवल 22 को ही target करते हैं। यदि आप ऐसा करना चाहते हैं, तो अपनी drop-in file में Port 2222 जोड़ें, पहले firewall में नए port को allow करें, फिर sudo systemctl daemon-reload && sudo systemctl restart ssh.socket चलाएं और ssh -p 2222 के साथ connect करें। Ubuntu 24.04 पर, ssh.socket listening port को नियंत्रित करता है, इसलिए केवल reload ssh चलाने से sshd port 22 पर ही रहता है; socket को restart करने पर ही नया port लागू होता है। इसे सुरक्षा के बजाय केवल व्यवस्था (tidiness) के रूप में देखें।

चरण 5: अतिरिक्त सुरक्षा परतें जोड़ना

Hardened SSH keys सुरक्षा की नींव हैं, और इनके ऊपर दो और परतें काम करती हैं।

Fail2ban आपके logs की निगरानी करता है और उन addresses को ban कर देता है जो बार-बार login करने में विफल रहते हैं। यह scanner के शोर को कम करता है और उन्हें जल्दी बाहर निकाल देता है। यह key-only authentication के साथ बहुत प्रभावी ढंग से काम करता है: देखें SSH हमलों को रोकने के लिए Ubuntu पर Fail2ban।

इससे भी बेहतर तरीका यह है कि SSH को पूरी तरह से public internet से दूर रखा जाए। यदि आप SSH को WireGuard VPN के पीछे रखते हैं और port 22 को firewall के जरिए केवल tunnel तक सीमित कर देते हैं, तो VPN के बाहर का कोई भी व्यक्ति इसे access नहीं कर पाएगा। इससे brute-force हमले केवल कठिन ही नहीं, बल्कि असंभव हो जाते हैं। यह सब एक default-deny firewall पर आधारित है, जो VPS पर UFW setup के माध्यम से किया जाता है।

SSH एक बड़ी checklist का केवल एक हिस्सा है: नए VPS पर शुरुआती 10 मिनट इन चरणों को सही क्रम में रखता है, और Ubuntu पर automatic security updates बाद में server को सुरक्षित रखते हैं। केवल दरवाजा बंद कर देने से उसके पीछे चल रही services सुरक्षित नहीं हो जातीं। इसलिए, यदि इसी VPS पर कोई password vault चल रहा है, तो Vaultwarden की सुरक्षा को मजबूत करना उन दो चीजों को कवर करता है जिन्हें key authentication नहीं छू सकता: इसका admin token और इसकी backup file।

FAQ

Ubuntu 24.04 पर SSH के लिए पासवर्ड लॉगिन कैसे बंद करें?

/etc/ssh/sshd_config.d/00-hardening.conf पर एक drop-in फाइल बनाएँ (00 प्रीफिक्स इसे 50-cloud-init.conf से पहले क्रमबद्ध करता है, क्योंकि PasswordAuthentication yes के बिना sshd पहले मिलने वाले मान को ही रखता है)। इसमें PasswordAuthentication no और KbdInteractiveAuthentication no शामिल करें, इसे जाँचने के लिए sudo sshd -t चलाएँ, और फिर sudo systemctl reload ssh करें। भरोसा करने से पहले एक नए सेशन में पुष्टि करें कि की-आधारित (key-based) लॉगिन काम कर रहा है। sshd_config को सीधे एडिट करने के बजाय drop-in फाइल का उपयोग करने से यह package upgrades के बाद भी सुरक्षित रहता है और इसे हटाना आसान होता है।

क्या मुझे SSH के माध्यम से root लॉगिन बंद कर देना चाहिए?

हाँ। PermitRootLogin no सेट करें ताकि कोई भी सीधे root के रूप में लॉगिन न कर सके। अपने सामान्य यूजर के रूप में लॉगिन करें और एडमिन कार्यों के लिए sudo का उपयोग करें। हर Linux सिस्टम पर root मौजूद होता है, इसलिए इसे खुला छोड़ने का मतलब है कि हमलावर को एक ज्ञात यूजरनेम मिल जाता है। इसे बंद करने का अर्थ है कि हमलावर को आपका अकाउंट नाम जानना होगा और आपकी की (key) भी होनी चाहिए।

क्या SSH पोर्ट बदलने से मेरा सर्वर अधिक सुरक्षित हो जाता है?

वास्तविक रूप से नहीं। पोर्ट 22 से हटने पर आप उन आलसी स्कैनर्स से बच जाते हैं जो केवल 22 को ही स्कैन करते हैं, जिससे लॉग में शोर कम होता है, लेकिन एक वास्तविक हमलावर हर पोर्ट को स्कैन करेगा और उसे ढूँढ ही लेगा। की-ओनली ऑथेंटिकेशन (key-only authentication) ही वह चीज है जो वास्तव में घुसपैठ को रोकती है। यदि आप पोर्ट बदलते हैं, तो पहले फायरवॉल में नया पोर्ट खोलें, फिर sudo systemctl daemon-reload && sudo systemctl restart ssh.socket चलाएँ; Ubuntu 24.04 पर सॉकेट लिसनर को नियंत्रित करता है, और केवल reload करने से sshd पोर्ट 22 पर ही बना रहता है।

यदि मैं SSH की (keys) का उपयोग करता हूँ, तो क्या मुझे Fail2ban की आवश्यकता है?

यह वैकल्पिक है लेकिन फिर भी उपयोगी है। की-ओनली ऑथेंटिकेशन के साथ, पासवर्ड का अनुमान लगाना सफल नहीं हो सकता, इसलिए Fail2ban हमलावरों को बाहर रखने का मुख्य साधन नहीं है। यह एक ही पते से बार-बार होने वाली विफलताओं को सीमित करता है, जो आपके लॉग से स्कैनर के शोर को कम करता है और बार-बार परेशान करने वालों को जल्दी बाहर निकाल देता है; एक धीमा, वितरित हमला वैसे भी इसकी बैन सीमा के नीचे ही रहता है। इसे की-ऑथेंटिकेशन के साथ चलाएँ, और आदर्श रूप से SSH को VPN के पीछे रखें।

यदि मैं SSH से बाहर हो जाऊँ (lockout), तो रिकवर कैसे करूँ?

अपने प्रोवाइडर के वेब कंसोल का उपयोग करें, जो सीरियल या VNC कनेक्शन के माध्यम से सर्वर तक पहुँचता है और SSH का उपयोग नहीं करता है। वहाँ से आप लॉगिन कर सकते हैं, sshd drop-in फाइल को ठीक कर सकते हैं, और सर्विस को रीलोड कर सकते हैं। यही कारण है कि आप अपना पहला सेशन बंद करने से पहले दूसरे टर्मिनल में नए SSH कॉन्फ़िगरेशन का परीक्षण करते हैं, और पासवर्ड बंद करने से पहले की-ऑथेंटिकेशन का काम करना सुनिश्चित करते हैं।