VPS वर SSH secure कसे करायचे

SSH कडक (harden) करणे सर्वात महत्त्वाचे का आहे

SSH द्वारे तुम्ही तुमच्या server वर नियंत्रण मिळवता, त्यामुळेच हल्लेखोर (attackers) सर्वात आधी याच लॉकवर हल्ला करण्याचा प्रयत्न करतात. VPS online आल्यानंतर लगेच, scanners port 22 वर usernames आणि passwords चा अंदाज लावायला सुरुवात करतात. काही मिनिटांतच तुम्ही तुमच्या logs मध्ये ही प्रक्रिया पाहू शकता. SSH harden करणे म्हणजे हल्लेखोरांना अंदाज लावता येतील अशा गोष्टी काढून टाकणे: password login पूर्णपणे बंद करा, root login बंद करा आणि फक्त cryptographic keys ला परवानगी द्या. एकदा तुम्ही हे केले की, सततचे guessing यशस्वी होऊ शकत नाही, कारण शोधण्यासाठी तिथे कोणताही password उरत नाही.

हे गृहीत धरले आहे की तुमचे SSH आधीच कार्यरत आहे. जर तुम्ही log in करू शकत असाल, तर तुम्ही ते harden करू शकता. सर्व पायऱ्या क्रमाने करा आणि जोपर्यंत नवीन session यशस्वी होत नाही तोपर्यंत तुमचे सध्याचे session उघडे ठेवा, जेणेकरून चुकीमुळे तुम्ही system मधून बाहेर (lock out) पडणार नाही.

Step 1: प्रथम key authentication कार्यरत असल्याची खात्री करा

Key authentication मध्ये password च्या जागी key pair वापरले जाते: एक private key जे तुमच्या computer वर राहते आणि एक public key जे तुम्ही server वर ठेवता. private key तुमच्या machine वरून बाहेर न जाताच server तुमची ओळख पटवते. Password disable करण्यापूर्वी, keys काम करत असल्याची खात्री करा, अन्यथा तुम्ही स्वतःला system मधून lock करू शकता.

तुमच्या स्वतःच्या computer वर, जर तुमच्याकडे key नसेल तर ती तयार करा:

ssh-keygen -t ed25519

Public half server वर copy करा:

ssh-copy-id user@your-server

त्यानंतर एक नवीन SSH session उघडा. जर password न विचारता तुम्हाला login करता आले, तर तुमची key कार्यरत आहे आणि तुम्ही passwords बंद करण्यास सुरक्षित आहात. जर तुम्हाला keys बद्दल माहिती नसेल किंवा तुम्ही एकापेक्षा जास्त computer वापरत असाल, तर SSH key management basics मध्ये संपूर्ण मॉडेल स्पष्ट केले आहे: प्रत्येक device साठी एक key, sshd कडून आवश्यक असलेल्या permissions, आणि laptop हरवल्यास key कशी रद्द (revoke) करायची याची माहिती.

Step 2: drop-in file वापरून sshd सुरक्षित करा

/etc/ssh/sshd_config फाईल थेट संपादित करू नका. Ubuntu 24.04 मध्ये /etc/ssh/sshd_config.d/ मधून drop-in फाईल्स वाचल्या जातात. तिथे एक छोटी फाईल तयार करणे अधिक सोयीचे ठरते, कारण ती package upgrades दरम्यान सुरक्षित राहते आणि काही चूक झाल्यास सहज काढता येते. फाईलचे नाव महत्त्वाचे आहे: sshd प्रत्येक सेटिंगसाठी पहिली वाचलेली व्हॅल्यू वापरते. Ubuntu cloud images मध्ये PasswordAuthentication yes ही फाईल 50-cloud-init.conf या निर्देशिकेमध्ये (directory) असते. तुमची फाईल 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 attack साठी कोणताही मार्ग उरत नाही. KbdInteractiveAuthentication no पासवर्ड-आधारित दुसरा मार्ग बंद करते. PermitRootLogin no मुळे हल्लेखोराला केवळ root खाते लक्षित न करता, तुमचे username आणि तुमची key माहित असणे आवश्यक आहे.

Step 3: Test the config, then reload

Apply करण्यापूर्वी config मध्ये चुका आहेत का ते तपासा, जेणेकरून टायपोमुळे service बंद होणार नाही:

sudo sshd -t

जर काहीही प्रिंट झाले नाही, तर config वैध (valid) आहे. SSH reload करा:

sudo systemctl reload ssh

त्यानंतर sshd प्रत्यक्षात कोणते settings वापरत आहे ते तपासा, जेणेकरून दुसऱ्या फाईलमुळे झालेली चूक लक्षात येईल:

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

दोन्हीमध्ये no असे दिसायला हवे. आता, सध्याचे session बंद न करता, दुसऱ्या terminal मधून नवीन session उघडा. जर तुमच्या key ने login झाले, तर तुमचे काम पूर्ण झाले आहे. जर काही चूक झाली, तर ती सुधारण्यासाठी तुमचे पहिले session अजूनही उघडे आहे. ही पद्धत एक safety net म्हणून काम करते, त्यामुळे ती कधीही वगळू नका.

Step 4: The optional non-standard port

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

Step 5: Layer the further defences

Hardened SSH keys हे पायाभूत घटक आहेत, आणि त्यांच्या वर आणखी दोन सुरक्षा स्तर (layers) आहेत.

Fail2ban तुमच्या logs वर लक्ष ठेवते आणि वारंवार अयशस्वी होणारे addresses ban करते. यामुळे scanner noise कमी होतो आणि हल्लेखोर लवकर बाहेर काढले जातात. हे key-only auth सोबत उत्तम काम करते: Fail2ban on Ubuntu to stop SSH attacks पहा.

SSH पूर्णपणे public internet वरून काढून टाकणे अधिक सुरक्षित आहे. जर तुम्ही put SSH behind a WireGuard VPN केले आणि firewall port 22 फक्त tunnel साठी मर्यादित ठेवले, तर VPN च्या बाहेरून कोणीही SSH पर्यंत पोहोचू शकणार नाही. यामुळे brute-force attacks केवळ कठीण न होता पूर्णपणे अशक्य होतात. या सर्वासाठी default-deny firewall असणे आवश्यक आहे, जसे की UFW set up on the VPS.

SSH हा एका मोठ्या checklist मधील एक भाग आहे: the first 10 minutes on a new VPS मध्ये सर्व पायऱ्या क्रमाने दिल्या आहेत, आणि automatic security updates on Ubuntu मुळे सर्व patches अपडेट राहतात.

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 होते, अन्यथा PasswordAuthentication yes लागू होईल, कारण sshd प्रथम वाचलेली value स्वीकारते) ज्यामध्ये PasswordAuthentication no आणि KbdInteractiveAuthentication no असेल. तपासण्यासाठी sudo sshd -t चालवा आणि नंतर sudo systemctl reload ssh करा. पूर्णपणे अवलंबून होण्यापूर्वी नवीन session मध्ये key login काम करते की नाही याची खात्री करा. sshd_config ऐवजी drop-in file संपादित केल्यामुळे package upgrades दरम्यान सेटिंग्ज सुरक्षित राहतात आणि ते बदलणे सोपे असते.

मी SSH वरून root login अक्षम करावे का?

हो. PermitRootLogin no सेट करा जेणेकरून कोणीही थेट root म्हणून log in करू शकणार नाही. तुमच्या सामान्य user ने log in करा आणि admin कामांसाठी sudo वापरा. प्रत्येक Linux system वर root असतो, त्यामुळे तो उपलब्ध ठेवल्यास हल्लेखोराला लक्ष्य करण्यासाठी एक ज्ञात username मिळते. तो अक्षम केल्यामुळे, हल्लेखोराला तुमचे account name माहित असणे आणि तुमच्याकडे तुमची key असणे आवश्यक आहे.

SSH port बदलल्याने माझा server अधिक सुरक्षित होतो का?

नाही, त्याचा फारसा उपयोग होत नाही. port 22 वरून हलल्यामुळे केवळ 22 port probe करणाऱ्या lazy scanners पासून तुम्ही वाचता, ज्यामुळे log noise कमी होतो; परंतु खरा हल्लेखोर सर्व ports scan करतो आणि तो port शोधून काढतोच. key-only authentication हेच खऱ्या अर्थाने घुसखोरी थांबवते. जर तुम्ही port बदलला, तर प्रथम firewall मध्ये नवीन port open करा आणि नंतर sudo systemctl daemon-reload && sudo systemctl restart ssh.socket चालवा; Ubuntu 24.04 मध्ये socket listener नियंत्रित करतो, त्यामुळे केवळ reload केल्यास sshd port 22 वरच राहते.

मी SSH keys वापरत असल्यास मला Fail2ban ची गरज आहे का?

ते ऐच्छिक आहे पण तरीही उपयुक्त आहे. key-only authentication मुळे password guessing यशस्वी होऊ शकत नाही, त्यामुळे Fail2ban हल्लेखोरांना रोखण्याचे मुख्य साधन नाही. ते एकाच address वरून होणारे वारंवारचे failures rate-limit करते, ज्यामुळे logs मधील scanner noise कमी होतो आणि वारंवार offense करणाऱ्यांना लवकर बाहेर काढले जाते; संथ आणि distributed attack तरीही त्याच्या ban threshold च्या खाली राहतो. key auth सोबतच ते चालवा आणि शक्य असल्यास SSH ला VPN च्या मागे ठेवा.

जर मी स्वतःला SSH मधून lock out केले तर मी कसे recover करू?

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