VPS पर SSH कैसे secure करें

SSH को harden करना सबसे पहला कदम क्यों है

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

यह मानकर चला गया है कि आपका SSH पहले से ही काम कर रहा है। यदि आप log in कर सकते हैं, तो आप इसे harden कर सकते हैं। सभी steps को क्रम से करें और अपने current session को तब तक खुला रखें जब तक कि नया session काम न करने लगे, ताकि कोई गलती आपको बाहर (lock out) न कर दे।

Step 1: Pehle yeh confirm karein ki key authentication kaam kar raha hai

Key authentication password ki jagah ek key pair ka upyog karta hai: ek private key jo aapke computer par rehti hai, aur ek public key jo aap server par rakhte hain. Server yeh verify karta hai ki aapke paas private key hai, bina use aapki machine se bahar bheje. Password disable karne se pehle, keys ke kaam karne ki pushti kar lein, warna aap apne aap ko lock kar lenge.

Agar aapke paas key nahi hai, toh apne computer par ek key banayein:

ssh-keygen -t ed25519

Public half ko server par copy karein:

ssh-copy-id user@your-server

Iske baad ek naya SSH session open karein. Agar yeh bina password maange aapko login karne deta hai, toh aapki key kaam kar rahi hai aur aap passwords band karne ke liye surakshit hain. Agar aap keys ke liye naye hain, ya aap ek se zyada computer ka upyog karte hain, toh SSH key management basics poore model ko samjhata hai: har device ke liye ek key, sshd dwara maangi gayi permissions, aur laptop khone par key ko revoke karne ka tarika.

Step 2: Drop-in file के साथ sshd को harden करें

/etc/ssh/sshd_config को सीधे edit न करें। Ubuntu 24.04, /etc/ssh/sshd_config.d/ से drop-in files पढ़ता है। वहां एक छोटी file रखना बेहतर है क्योंकि यह cleaner होती है, package upgrades के दौरान सुरक्षित रहती है, और समस्या होने पर इसे हटाना आसान होता है। File का नाम महत्वपूर्ण है: sshd प्रत्येक setting के लिए पहली value को ही स्वीकार करता है। Ubuntu cloud images में इस directory में PasswordAuthentication yes के साथ 50-cloud-init.conf मिलता है। अपनी file का नाम 00- रखें ताकि वह उस file से पहले sort हो और प्राथमिकता प्राप्त करे; 99- file बिना किसी error के ignore हो जाएगी। एक file बनाएं:

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

प्रत्येक line एक security gap को बंद करती है। PasswordAuthentication no सबसे महत्वपूर्ण है: passwords बंद करने से brute-force attack का प्रभाव खत्म हो जाता है। KbdInteractiveAuthentication no password-style access के दूसरे रास्ते को बंद करता है। PermitRootLogin no का अर्थ है कि attacker को आपका username पता होना चाहिए और उसके पास आपकी key होनी चाहिए; वह केवल root account को target नहीं कर सकता जो हर system पर मौजूद होता है।

Step 3: Config का परीक्षण करें, फिर reload करें

Config को लागू करने से पहले गलतियों के लिए उसकी जाँच करें, ताकि किसी typo से service खराब न हो जाए:

sudo sshd -t

यदि कुछ भी प्रिंट नहीं होता है, तो config सही है। SSH को reload करें:

sudo systemctl reload ssh

फिर उन settings की जाँच करें जिन्हें sshd वास्तव में उपयोग कर रहा है, ताकि यदि कोई configuration किसी अन्य file के कारण ओवरराइड हो गया हो, तो आप उसे पकड़ सकें:

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

दोनों में no दिखना चाहिए। अब, अपना वर्तमान session बंद किए बिना, किसी अन्य terminal से एक नया session खोलें। यदि यह आपकी key के साथ login कर लेता है, तो आपका काम पूरा हो गया है। यदि कुछ भी गलत है, तो आपकी पहली session अभी भी खुली है ताकि आप उसे ठीक कर सकें। यह overlap एक safety net है, इसलिए इसे कभी न छोड़ें।

Step 4: Optional non-standard port

SSH को port 22 से बदलकर 2222 जैसा port देना वास्तविक सुरक्षा प्रदान नहीं करता है, क्योंकि एक हमलावर सभी ports को scan करता है। इसका मुख्य लाभ log noise को कम करना है, क्योंकि अधिकांश automated scanners केवल 22 port का उपयोग करते हैं। यदि आप ऐसा करना चाहते हैं, तो अपनी 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 को manage करता है, इसलिए साधारण reload ssh के साथ sshd port 22 पर ही रहता है; नए port को लागू करने के लिए socket को restart करना आवश्यक है। इसे सुरक्षा के बजाय system tidiness के रूप में देखें।

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

Hardened SSH keys आधार हैं, और इनके ऊपर दो और परतें काम करती हैं।

Fail2ban आपके logs की निगरानी करता है और बार-बार fail होने वाले addresses को ban कर देता है। इससे scanner noise कम होती है और हमलावर जल्दी बाहर हो जाते हैं। यह key-only auth के साथ बेहतर काम करता है: देखें Ubuntu पर SSH attacks रोकने के लिए Fail2ban।

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

SSH एक बड़ी checklist का हिस्सा है: नए VPS पर पहले 10 मिनट के चरणों का पालन करें, और Ubuntu पर automatic security updates के माध्यम से system को patch रखें।

FAQ

Ubuntu 24.04 पर SSH के लिए password login को कैसे disable करें?

/etc/ssh/sshd_config.d/00-hardening.conf पर एक drop-in file बनाएँ (00 prefix के कारण यह 50-cloud-init.conf से पहले sort होगा; अन्यथा 50-cloud-init.conf की PasswordAuthentication yes जीत जाएगी, क्योंकि sshd सबसे पहले पढ़ी गई value का उपयोग करता है)। इसमें PasswordAuthentication no और KbdInteractiveAuthentication no लिखें, फिर check करने के लिए sudo sshd -t चलाएँ, और अंत में sudo systemctl reload ssh करें। इस पर भरोसा करने से पहले एक नए session में key login को confirm करें। sshd_config के बजाय drop-in file को edit करने से package upgrades के दौरान settings सुरक्षित रहती हैं और इसे undo करना आसान होता है।

क्या मुझे SSH पर root login disable कर देना चाहिए?

हाँ। PermitRootLogin no सेट करें ताकि कोई भी सीधे root के रूप में log in न कर सके। अपने normal user के रूप में log in करें और admin tasks के लिए sudo का उपयोग करें। हर Linux system पर root मौजूद होता है, इसलिए इसे reachable रखने से हमलावर को target करने के लिए एक known username मिल जाता है। इसे disable करने का मतलब है कि हमलावर को आपके account name और आपकी key दोनों की आवश्यकता होगी।

क्या SSH port बदलने से मेरा server अधिक secure बनता है?

इसका कोई खास प्रभाव नहीं पड़ता। Port 22 से हटकर move करने से आप उन lazy scanners से बच जाते हैं जो केवल port 22 को probe करते हैं, जिससे log noise कम होती है। लेकिन एक वास्तविक हमलावर हर port को scan करता है और उसे ढूंढ ही लेगा। Key-only authentication ही वास्तव में break-ins को रोकता है। यदि आप port बदलते हैं, तो पहले firewall में नया port open करें, फिर sudo systemctl daemon-reload && sudo systemctl restart ssh.socket चलाएँ; Ubuntu 24.04 पर socket listener को manage करता है, और केवल reload करने से sshd port 22 पर ही रहता है।

क्या SSH keys का उपयोग करने पर मुझे Fail2ban की आवश्यकता है?

यह optional है लेकिन फिर भी उपयोगी है। Key-only authentication के साथ, password guessing सफल नहीं हो सकता, इसलिए Fail2ban हमलावरों को रोकने का मुख्य साधन नहीं है। यह एक ही address से होने वाले repeated failures को rate-limit करता है, जिससे logs में scanner noise कम होती है और repeat offenders को जल्दी block किया जा सकता है; एक slow, distributed attack वैसे भी इसके ban threshold से नीचे रहता है। Key auth के साथ इसे चलाएँ, और आदर्श रूप से SSH को VPN के पीछे रखें।

यदि मैं SSH से खुद को lock out कर लूँ तो recovery कैसे करें?

अपने provider के web console का उपयोग करें। यह server तक serial या VNC connection के माध्यम से पहुँचता है जो SSH के माध्यम से नहीं जाता है। वहां से आप log in कर सकते हैं, sshd drop-in file को ठीक कर सकते हैं, और service को reload कर सकते हैं। यही कारण है कि आपको अपना पहला session बंद करने से पहले दूसरे terminal में नई SSH config को test करना चाहिए, और passwords बंद करने से पहले key authentication का काम करना सुनिश्चित करना चाहिए।