VPS वर SSH hardening: सुरक्षित login साठी मार्गदर्शक

SSH प्रथम सुरक्षित का करावे

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

यासाठी SSH आधीपासून कार्यरत असणे आवश्यक आहे. तुम्ही login करू शकत असाल, तर SSH harden करू शकता. हे टप्पे क्रमाने करा आणि नवीन session यशस्वीरीत्या कार्य करेपर्यंत सध्याचे session खुले ठेवा. त्यामुळे चुकीच्या बदलामुळे तुमचा access बंद होणार नाही.

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

Key authentication मध्ये password ऐवजी key pair वापरला जातो: private key तुमच्या संगणकावरच राहतो आणि public key तुम्ही सर्व्हरवर ठेवता. private key तुमच्या संगणकाबाहेर न जाता, तो तुमच्याकडे आहे हे सर्व्हर पडताळतो. Password authentication बंद करण्यापूर्वी keys कार्यरत असल्याची खात्री करा; अन्यथा तुम्ही स्वतःच सर्व्हरबाहेर लॉक होऊ शकता.

तुमच्या स्वतःच्या संगणकावर key नसल्यास तो तयार करा:

ssh-keygen -t ed25519

Public key चा भाग सर्व्हरवर कॉपी करा:

ssh-copy-id user@your-server

त्यानंतर नवीन SSH session उघडा. Password विचारल्याशिवाय प्रवेश मिळत असेल, तर तुमचा key कार्यरत आहे आणि passwords बंद करणे सुरक्षित आहे. Permission denied (publickey) आल्यास, त्या एका त्रुटीमागे पाच वेगवेगळ्या समस्या लपलेल्या असतात, आणि पुढे काहीही बदलण्यापूर्वी ssh -v output तुमच्याकडे त्यापैकी कोणती समस्या आहे ते सांगतो. Keys तुमच्यासाठी नवीन असतील किंवा तुम्ही एकापेक्षा जास्त संगणक वापरत असाल, तर SSH key management ची मूलभूत माहिती या पूर्ण पद्धतीचे स्पष्टीकरण देते: प्रत्येक device साठी एक key, sshd ला आवश्यक असलेले permissions आणि laptop हरवल्यास key revoke करण्याची पद्धत.

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

/etc/ssh/sshd_config थेट संपादित करू नका. Ubuntu 24.04 /etc/ssh/sshd_config.d/ मधून drop-in files वाचते. तेथे ठेवलेली लहान file अधिक स्वच्छ असते, package upgrades नंतरही टिकते आणि काही चूक झाल्यास काढणे सोपे असते. नाव महत्त्वाचे आहे: sshd प्रत्येक setting साठी प्रथम वाचलेली value ठेवतो. Ubuntu cloud images या directory मध्ये 50-cloud-init.conf आणि PasswordAuthentication yes सह वितरित होतात. तुमच्या file चे नाव 00- ठेवा, जेणेकरून ती त्या file च्या आधी sort होईल आणि तिची value लागू होईल; 99- file असल्यास तिची value शांतपणे दुर्लक्षित होते. एक 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

प्रत्येक ओळ एक प्रवेशमार्ग बंद करते. PasswordAuthentication no हा सर्वात महत्त्वाचा पर्याय आहे: passwords बंद असल्याने brute-force attack करण्यासाठी काहीही उरत नाही. KbdInteractiveAuthentication no दुसरा password-आधारित मार्ग बंद करते. PermitRootLogin no मुळे हल्लेखोराला तुमचे username माहीत असणे आणि तुमची key असणे आवश्यक ठरते. प्रत्येक box वर अस्तित्वात असलेल्या एकाच account, root, ला लक्ष्य करणे पुरेसे राहत नाही.

पायरी 3: Configuration तपासा आणि नंतर reload करा

Configuration लागू करण्यापूर्वी त्यात काही चुका आहेत का ते तपासा. त्यामुळे एखाद्या टायपिंगच्या चुकीमुळे service बंद पडणार नाही:

sudo sshd -t

यातून काहीही output मिळाले नाही, तर configuration valid आहे. SSH reload करा:

sudo systemctl reload ssh

त्यानंतर sshd प्रत्यक्षात वापरत असलेल्या settings तपासा. त्यामुळे दुसऱ्या file मधील configuration मुळे drop-in configuration दुर्लक्षित झाली आहे का ते समजेल:

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

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

पायरी 4: पर्यायी अशासकीय पोर्ट

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

पायरी 5: पुढील संरक्षणाचे स्तर जोडा

सुरक्षित केलेल्या SSH keys हा पाया आहे. त्यावर आणखी दोन संरक्षणाचे स्तर लागू करता येतात.

Fail2ban तुमचे logs monitor करते आणि वारंवार अपयशी प्रयत्न करणाऱ्या addresses वर ban लावते. त्यामुळे scanner मुळे निर्माण होणारा अनावश्यक log traffic कमी होतो आणि अशा addresses ना लवकरच बाहेर ठेवता येते. Key-only authentication सोबत ही रचना नैसर्गिकपणे जुळते: SSH हल्ले थांबवण्यासाठी Ubuntu वर Fail2ban पहा.

याहून मजबूत उपाय म्हणजे SSH सार्वजनिक इंटरनेटवर पूर्णपणे उपलब्ध न ठेवणे. तुम्ही WireGuard VPN मागे SSH ठेवले आणि port 22 फक्त tunnel कडे firewall ने परवानगी दिली, तर VPN च्या बाहेरील कोणीही SSH पर्यंत पोहोचू शकणार नाही. त्यामुळे brute-force guessing फक्त कठीण न राहता अशक्य होते. या सर्वांसाठी खाली default-deny firewall असणे गृहीत आहे. त्यासाठी VPS वर UFW सेट करा.

SSH हा मोठ्या checklist मधील एकच भाग आहे: नवीन VPS वरील पहिल्या 10 मिनिटांत या पायऱ्या योग्य क्रमाने दिल्या आहेत. त्यानंतर Ubuntu वर automatic security updates सर्व्हरला अद्ययावत ठेवतात. SSH सुरक्षित केल्याने त्यामागील services सुरक्षित होत नाहीत. त्यामुळे याच VPS वर password vault चालत असल्यास, Vaultwarden चे hardening करा या पद्धतीत key authentication च्या कक्षेबाहेरील दोन गोष्टी समाविष्ट आहेत: त्याचा admin token आणि backup file.

FAQ

SSH साठी Ubuntu 24.04 मध्ये password login कसे बंद करावे?

/etc/ssh/sshd_config.d/00-hardening.conf येथे drop-in file तयार करा. 00 prefix मुळे ही file 50-cloud-init.conf च्या आधी क्रमवारीत येते. अन्यथा PasswordAuthentication yes मधील value लागू झाली असती, कारण sshd वाचलेली पहिली value ठेवतो. त्या file मध्ये PasswordAuthentication no आणि KbdInteractiveAuthentication no समाविष्ट करा. Configuration तपासण्यासाठी sudo sshd -t चालवा. त्यानंतर sudo systemctl reload ssh चालवा. त्यावर अवलंबून राहण्यापूर्वी नवीन session मध्ये key login कार्यरत आहे याची खात्री करा. sshd_config संपादित करण्याऐवजी drop-in file वापरल्यास package upgrades नंतरही बदल टिकतो आणि तो सहज पूर्ववत करता येतो.

SSH द्वारे root login बंद करावे का?

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

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

लक्षणीयरीत्या नाही. Port 22 ऐवजी दुसरा port वापरल्यास फक्त port 22 तपासणाऱ्या निष्काळजी scanners पासून server लपतो. त्यामुळे logs मधील अनावश्यक नोंदी कमी होतात. परंतु प्रत्यक्ष आक्रमणकर्ता प्रत्येक port scan करतो आणि हा port शोधतो. Break-in प्रत्यक्षात थांबवणारी गोष्ट म्हणजे key-only authentication. Port बदलत असल्यास आधी firewall मध्ये नवीन port उघडा. त्यानंतर sudo systemctl daemon-reload && sudo systemctl restart ssh.socket चालवा. Ubuntu 24.04 मध्ये listener चे नियंत्रण socket कडे असते. त्यामुळे साधा reload केल्यास sshd port 22 वरच सुरू राहतो.

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

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

SSH मधून स्वतःला lock out केल्यास पुन्हा प्रवेश कसा मिळवावा?

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