परिचय
लिनक्स ऑपरेटिंग सिस्टम में जब भी कोई नया कमांड इंटरप्रेटर इंस्टॉल किया जाता है या उपयोगकर्ताओं के लिए कोई कस्टम बैश स्क्रिप्ट लॉगिन इंटरफेस के रूप में लागू करनी होती है, तब add-shell यूटिलिटी की भूमिका अत्यंत महत्वपूर्ण हो जाती है। यह व्यावहारिक ट्यूटोरियल गहराई से समझाता है कि लिनक्स कर्नेल और ऑथेंटिकेशन मॉड्यूल /etc/shells डेटाबेस पर किस तरह निर्भर करते हैं। इस गाइड में हम वैध शेल्स की जांच, कस्टम एनवायरनमेंट को सिस्टम शेल के रूप में ऑथराइज करना, chsh के साथ अकाउंट मैपिंग, और काम पूरा होने के बाद remove-shell की मदद से साफ-सुथरा डी-रजिस्ट्रेशन करना चरणबद्ध तरीके से सीखेंगे।
1. /etc/shells की तकनीकी भूमिका और वैध शेल लिस्टिंग का विश्लेषण
लिनक्स परिवेश में कौन-कौन से शेल उपयोगकर्ता सत्रों के लिए आधिकारिक तौर पर स्वीकृत हैं, इसकी सूची देखने के लिए टर्मिनल में cat /etc/shells निष्पादित किया जाता है।
सुरक्षा की दृष्टि से यह फ़ाइल एक गेटकीपर का कार्य करती है— केवल वही पाथ जिन्हें इस डेटाबेस में सूचीबद्ध किया गया है, गैर-रूट उपयोगकर्ताओं द्वारा chsh (change shell) के माध्यम से चुने जा सकते हैं। साथ ही, FTP/SSH डेमन्स (जैसे vsftpd) भी प्रमाणीकरण के दौरान इस सूची का सत्यापन करते हैं।
सिस्टम में पहले से मौजूद बुनियादी शेल्स के सटीक बाइनरी पाथ जानने के लिए हम which bash sh कमांड की सहायता लेते हैं।
परिणामस्वरूप मिलने वाले /usr/bin/bash और /usr/bin/sh पथों का मिलान जब /etc/shells के रिकॉर्ड्स से किया जाता है, तो यह स्पष्ट हो जाता है कि वर्तमान सिस्टम इन दोनों को पूर्णतः अधिकृत शेल मानता है।
2. पैकेज मैनेजर से Zsh डिप्लॉयमेंट और add-shell पंजीकरण प्रक्रिया
प्रायोगिक अभ्यास के लिए हम एक लोकप्रिय वैकल्पिक शेल zsh को अपने सिस्टम रिपॉजिटरी से डाउनलोड और इंस्टॉल करने के लिए निम्न कमांड चलाते हैं।
बाइनरी सही स्थान पर स्थापित हुई है या नहीं, इसका एब्सोल्यूट पाथ खोजने के लिए which zsh रन किया जाता है।
यदि टर्मिनल आउटपुट खाली रहता है, तो इसका स्पष्ट संकेत है कि या तो पैकेज इंस्टॉलेशन में कोई समस्या आई है अथवा सिस्टम पाथ वेरिएबल उस निष्पादन योग्य फ़ाइल तक पहुँच नहीं पा रहा है।
जब sudo add-shell $(which zsh) को रन किया जाता है, तो सबशेल एक्सपेंशन के जरिए प्राप्त पाथ को स्वचालित रूप से /etc/shells में दर्ज किया जाना चाहिए।
हालाँकि, पिछले चरण में बाइनरी पाथ उपलब्ध न होने के कारण यह कमांड बिना किसी आर्गुमेंट के ट्रिगर हो जाती है, जिसके फलस्वरूप स्क्रीन पर यूटिलिटी का उपयोग सिंटैक्स (add-shell shellname) प्रदर्शित होता है।
क्या zsh वास्तव में सुरक्षा सूची में जोड़ा गया था? इसकी पड़ताल करने के लिए हम रेगुलर एक्सप्रेशन आधारित grep -E 'zsh$' /etc/shells चलाते हैं।
सर्च रिजल्ट में कोई भी लाइन मैच न होना यह साबित करता है कि फ़ाइल में अभी तक Zsh की एंट्री दर्ज नहीं हुई है।
3. कस्टम रिस्ट्रिक्टेड शेल स्क्रिप्ट का निर्माण और सिस्टम-स्तरीय प्राधिकरण
कई एंटरप्राइज परिदृश्यों में उपयोगकर्ताओं को पूर्ण बैश प्रॉम्प्ट देने के बजाय एक नियंत्रित मेनू इंटरफेस देना आवश्यक होता है। इसके लिए हम /usr/local/bin/custom-menu.sh पर एक स्वागत संदेश देने वाली स्क्रिप्ट तैयार करते हैं।
लिनक्स कर्नेल को इस स्क्रिप्ट को एक स्वतंत्र प्रक्रिया के रूप में शुरू करने की अनुमति देने हेतु sudo chmod +x /usr/local/bin/custom-menu.sh द्वारा एग्जीक्यूटेबल बिट सक्रिय किया जाता है।
साधारण स्क्रिप्ट को एक आधिकारिक लॉगिन शेल का दर्जा देने के लिए हम sudo add-shell /usr/local/bin/custom-menu.sh निष्पादित करते हैं, जो सीधे /etc/shells के अंतिम भाग में इस पाथ को सुरक्षित रूप से इंजेक्ट कर देता है।
फ़ाइल की ताज़ा स्थिति का मुआयना करने के लिए tail -n 3 /etc/shells रन किया जाता है।
आउटपुट के अंतिम भाग में /usr/local/bin/custom-menu.sh का उपस्थित होना यह प्रमाणित करता है कि अब हमारा लिनक्स सिस्टम इस स्क्रिप्ट को लॉगिन शेल के रूप में पूरी मान्यता प्रदान कर चुका है।
4. उपयोगकर्ता खाते से मैपिंग टेस्ट और remove-shell द्वारा सुरक्षित डी-कमीशनिंग
नव-पंजीकृत शेल की कार्यक्षमता जांचने के लिए हम sudo id -u testuser >/dev/null 2>&1 || sudo useradd -m -s /usr/local/bin/custom-menu.sh testuser के जरिए एक समर्पित परीक्षण यूजर (testuser) कॉन्फ़िगर करते हैं।
खाता निर्माण विनिर्देशों के अनुसार हुआ है या नहीं, यह जानने के लिए हम यूजर डेटाबेस से grep '^testuser:' /etc/passwd रिकॉर्ड फ़िल्टर करते हैं।
विवरण में अंतिम फ़ील्ड के रूप में /usr/local/bin/custom-menu.sh का दिखना यह स्पष्ट करता है कि सत्र आरंभ होते ही उपयोगकर्ता को सीधे हमारी कस्टम स्क्रिप्ट में रीडायरेक्ट किया जाएगा।
परीक्षण सफलतापूर्वक संपन्न होने के बाद, क्लीनअप प्रक्रिया के प्रथम चरण के रूप में sudo userdel -r testuser 2>/dev/null || true द्वारा यूजर अकाउंट और उसकी होम डायरेक्टरी को निष्कासित कर दिया जाता है।
अब चूंकि इस शेल की आवश्यकता समाप्त हो चुकी है, अतः सिस्टम सुरक्षा जोखिमों को कम करने के लिए sudo remove-shell /usr/local/bin/custom-menu.sh चलाकर इसे अधिकृत शेल सूची से बेदखल कर दिया जाता है।
फ़ाइल सिस्टम की स्वच्छता बनाए रखने के लिए भौतिक स्क्रिप्ट को sudo rm -f /usr/local/bin/custom-menu.sh कमांड से स्थायी रूप से हटा दिया जाता है।
अंतिम ऑडिट के तहत हम grep 'custom-menu.sh' /etc/shells || echo '등록 해제 완료' कमांड चलाकर पुष्टि करते हैं।
चूंकि फ़ाइल में यह पाथ अब मौजूद नहीं है, इसलिए टर्मिनल पर सफलता सूचक संदेश रिटर्न होता है, जो प्रमाणित करता है कि डी-रजिस्ट्रेशन त्रुटिरहित पूर्ण हुआ।
इस गाइड में हमने जाना कि लिनक्स सिस्टम में मैन्युअल रूप से संवेदनशील कॉन्फ़िगरेशन फ़ाइलों में बदलाव करने के बजाय add-shell और remove-shell जैसे मानकीकृत टूल्स का उपयोग करना कितना सुरक्षित और सुगम है। यह दृष्टिकोण न केवल मानवीय त्रुटियों (syntax errors) को रोकता है, बल्कि ऑडिट ट्रेल्स और ऑथेंटिकेशन सुरक्षा को भी सुदृढ़ बनाए रखता है।