मैं शेल स्क्रिप्ट में पासवर्ड कैसे छिपा सकता हूं? कई स्क्रिप्ट्स हैं जो डेटाबेस तक पहुंच रही हैं। यदि हम स्क्रिप्ट खोलते हैं तो अन्य लोग भी उपयोगकर्ता नाम और पासवर्ड से अवगत होते हैं। तो अगर किसी को पता है कि कैसे छिपाने के लिए कृपया मुझे बताएं।
मेरे पास एक तरीका है: पासवर्ड को एक फ़ाइल में रखें और फ़ाइल को छिपाएं और कोई भी फ़ाइल तक पहुंचने के लिए नहीं जा रहा है (अनुमतियों को बदलें और डेटाबेस तक पहुंचते समय स्क्रिप्ट में फ़ाइल का उपयोग करें)।
जवाबों:
पहला , जैसा कि कई लोग पहले ही कह चुके हैं, साख को स्क्रिप्ट से अलग रखना जरूरी है। (बढ़ी हुई सुरक्षा के अलावा, इसका मतलब यह भी है कि आप एक ही स्क्रिप्ट को विभिन्न क्रेडेंशियल वाली कई प्रणालियों के लिए फिर से इस्तेमाल कर सकते हैं)
दूसरा , आपको न केवल क्रेडेंशियल्स की सुरक्षा पर विचार करना चाहिए, बल्कि उन क्रेडेंशियल्स से समझौता किए जाने पर भी प्रभाव पड़ेगा। आपके पास डेटाबेस तक सभी पहुंच के लिए सिर्फ एक पासवर्ड नहीं होना चाहिए, आपके पास अलग-अलग स्तर के एक्सेस के साथ अलग-अलग क्रेडेंशियल्स होने चाहिए। उदाहरण के लिए, आपके पास एक डीबी उपयोगकर्ता हो सकता है जो डेटाबेस में खोज करने की क्षमता रखता है - उस उपयोगकर्ता के पास केवल-पढ़ने के लिए उपयोग होना चाहिए। किसी अन्य उपयोगकर्ता के पास नए रिकॉर्ड सम्मिलित करने की अनुमति हो सकती है, लेकिन उन्हें हटाने के लिए नहीं। किसी तीसरे व्यक्ति के पास रिकॉर्ड हटाने की अनुमति हो सकती है।
प्रत्येक खाते के लिए अनुमतियों को प्रतिबंधित करने के अलावा, आपको इस बात पर भी प्रतिबंध होना चाहिए कि प्रत्येक खाते का उपयोग कहां से किया जा सकता है। उदाहरण के लिए, आपके वेब सर्वर द्वारा उपयोग किए जाने वाले खाते को वेब सर्वर की तुलना में किसी अन्य आईपी पते से कनेक्ट करने की अनुमति नहीं दी जानी चाहिए। डेटाबेस के लिए पूर्ण रूट अनुमतियों वाला एक खाता वास्तव में बहुत प्रतिबंधित होना चाहिए, जहां से यह कनेक्ट हो सकता है और कभी भी इंटरेक्टिव रूप से उपयोग नहीं किया जाना चाहिए। डेटाबेस में संग्रहीत प्रक्रियाओं का उपयोग करने पर भी विचार करें ताकि यह सुनिश्चित किया जा सके कि प्रत्येक खाते द्वारा क्या किया जा सकता है।
इन प्रतिबंधों को सिस्टम के DB-सर्वर साइड पर लागू करने की आवश्यकता है, ताकि क्लाइंट पक्ष से समझौता करने पर भी प्रतिबंधों को इससे बदला नहीं जा सके। (और, जाहिर है, डीबी सर्वर को डीबी कॉन्फ़िगरेशन के अलावा फायरवॉल आदि के साथ संरक्षित करने की आवश्यकता है ...)
एक डीबी खाते के मामले में जिसे केवल सीमित रीड-ओनली एक्सेस की अनुमति है, और केवल एक विशेष आईपी पते से, आपको डेटा की संवेदनशीलता और होस्ट की स्क्रिप्ट की सुरक्षा के आधार पर, इससे आगे किसी भी क्रेडेंशियल्स की आवश्यकता नहीं हो सकती है। से चलाया जा रहा है। एक उदाहरण आपकी वेब साइट पर एक खोज फ़ॉर्म हो सकता है, जिसे एक उपयोगकर्ता के साथ चलाया जा सकता है जिसे केवल एक संग्रहीत प्रक्रिया का उपयोग करने की अनुमति है जो केवल उस जानकारी को निकालता है जिसे वेब पेज पर प्रस्तुत किया जाएगा। इस स्थिति में, पासवर्ड जोड़ना वास्तव में किसी भी अतिरिक्त सुरक्षा प्रदान नहीं करता है, क्योंकि यह जानकारी पहले से ही सार्वजनिक है, और उपयोगकर्ता किसी अन्य डेटा तक नहीं पहुंच सकता है जो अधिक संवेदनशील होगा।
यह भी सुनिश्चित करें कि डेटाबेस का कनेक्शन टीएलएस का उपयोग करके बनाया गया है, या नेटवर्क पर सुनने वाला कोई भी व्यक्ति आपकी साख प्राप्त कर सकता है।
तीसरा , विचार करें कि किस तरह की साख का उपयोग करना है। पासवर्ड केवल एक रूप हैं, और सबसे सुरक्षित नहीं हैं। इसके बजाय आप सार्वजनिक / निजी कुंजी जोड़ी, या AD / PAM या पसंद के कुछ रूप का उपयोग कर सकते हैं।
चौथा , उन शर्तों पर विचार करें जिनके तहत स्क्रिप्ट को चलाया जाएगा:
यदि यह अंतःक्रियात्मक रूप से चलाया जाता है, तो आपको पासवर्ड, या पासवर्ड को निजी कुंजी, या निजी कुंजी में दर्ज करना चाहिए, या वैध केर्बरोस टिकट के साथ लॉग इन किया जाना चाहिए, जब आप इसे चलाते हैं - दूसरे शब्दों में, स्क्रिप्ट को इसे प्राप्त करना चाहिए। उस समय आपसे सीधे तौर पर क्रेडेंशियल्स, जो आप इसे चलाते हैं, बजाय उन्हें किसी फ़ाइल से पढ़ने के।
यदि यह एक वेबसर्वर से चलाया जाता है, तो उस समय क्रेडेंशियल्स सेट करने पर विचार करें जब आप वेबसर्वर शुरू करते हैं। यहां एक अच्छा उदाहरण एसएसएल प्रमाणपत्र है - उनके पास एक सार्वजनिक प्रमाण पत्र और एक निजी कुंजी है, और निजी कुंजी में एक पासवर्ड है। आप वेबसर्वर पर निजी कुंजी संग्रहीत कर सकते हैं, लेकिन अपाचे शुरू करने के बाद भी आपको पासवर्ड दर्ज करना होगा। आप किसी प्रकार के हार्डवेयर, जैसे भौतिक कार्ड या HSM पर भी क्रेडेंशियल रख सकते हैं, जिसे सर्वर के चालू होने के बाद हटाया या लॉक किया जा सकता है। (बेशक, इस विधि के लिए नकारात्मक पक्ष यह है कि सर्वर कुछ भी होने पर अपने आप को पुनरारंभ नहीं कर सकता है। मैं इसे अपने सिस्टम से समझौता होने के जोखिम के लिए पसंद करूंगा, लेकिन आपका माइलेज भिन्न हो सकता है ...)
यदि स्क्रिप्ट को क्रोन से चलाया जा रहा है, तो यह कठिन हिस्सा है। आप नहीं चाहते हैं कि आपके सिस्टम में कहीं भी क्रेडेंशियल्स पड़े हों, जहां कोई उन्हें एक्सेस कर सके - लेकिन क्या आप चाहते हैं कि वे चारों ओर झूठ बोलें ताकि आपकी स्क्रिप्ट उन्हें एक्सेस कर सके, है ना? खैर, बिल्कुल सही नहीं है। ठीक से विचार करें कि स्क्रिप्ट क्या कर रही है। डेटाबेस को इसकी क्या अनुमति चाहिए? क्या इसे प्रतिबंधित किया जा सकता है ताकि कोई फर्क न पड़े कि गलत व्यक्ति उन अनुमतियों से जुड़ता है या नहीं? क्या आप इसके बजाय उस स्क्रिप्ट को सीधे DB सर्वर पर चला सकते हैं, जिस तक किसी और की पहुंच नहीं है, बजाय उस सर्वर से जिसके अन्य उपयोगकर्ता हैं? यदि किसी कारण है कि मैं सोच भी नहीं सकते, तो आप पूरी तरह चाहिए स्क्रिप्ट चल रहा है एक असुरक्षित सर्वर पर है और यह करना चाहिए कुछ खतरनाक / विनाशकारी करने में सक्षम हो ... अब अपनी वास्तुकला पर फिर से विचार करने का एक अच्छा समय है।
पांचवां , यदि आप अपने डेटाबेस की सुरक्षा को महत्व देते हैं, तो आपको इन लिपियों को उन सर्वरों पर नहीं चलाना चाहिए, जिनकी अन्य लोगों तक पहुंच है। यदि कोई आपके सिस्टम में लॉग इन है, तो उन्हें आपके क्रेडेंशियल्स पर प्राप्त करने की संभावना होगी । उदाहरण के लिए, एसएसएल प्रमाणपत्र के साथ एक वेबसर्वर के मामले में, किसी के पास रूट हासिल करने और httpd प्रक्रिया के मेमोरी क्षेत्र तक पहुंचने और क्रेडेंशियल्स को निकालने में सक्षम होने की कम से कम एक सैद्धांतिक संभावना है। हाल के दिनों में कम से कम एक शोषण हुआ है जहां ऐसा एसएसएल पर किया जा सकता है, यहां तक कि हमलावर को लॉग इन करने की भी आवश्यकता नहीं है।
इसके अलावा SELinux या apparmor का उपयोग करने पर विचार करें या जो कुछ भी आपके सिस्टम के लिए उपलब्ध है उसे प्रतिबंधित करें जो उपयोगकर्ता कर सकते हैं। वे उपयोगकर्ताओं को डेटाबेस से कनेक्ट करने का प्रयास करने के लिए भी अस्वीकार कर सकते हैं, भले ही वे क्रेडेंशियल्स तक पहुंच प्राप्त करने का प्रबंधन करते हों।
यदि यह सब आपको लगता है , और आप इसे बर्दाश्त नहीं कर सकते हैं या करने का समय नहीं है - तो, मेरी (अभिमानी और अभिजात्य) राय में, आपको अपने डेटाबेस में महत्वपूर्ण या संवेदनशील कुछ भी संग्रहीत नहीं करना चाहिए। और अगर आप कुछ भी महत्वपूर्ण या संवेदनशील नहीं जमा कर रहे हैं, तो जहाँ आप अपनी साख जमाते हैं, वह भी महत्वपूर्ण नहीं है - किस स्थिति में, एक पासवर्ड का उपयोग क्यों करें?
अंत में , यदि आप किसी तरह की साख जमा करने से बिल्कुल नहीं बच सकते हैं, तो आपके पास केवल और केवल जड़ के स्वामित्व वाली क्रेडेंशियल्स ही हो सकती हैं, जब कोई स्क्रिप्ट द्वारा ऐसा करने का अनुरोध किया जाता है, तो रूट और रूट एक अत्यधिक अस्थायी आधार पर स्वामित्व दे सकते हैं (क्योंकि आपकी स्क्रिप्ट नहीं होनी चाहिए जब तक बिल्कुल आवश्यक न हो, रूट के रूप में चलाएं और डेटाबेस से कनेक्ट करना आवश्यक नहीं है)। लेकिन यह अभी भी एक अच्छा विचार नहीं है।
सबसे पहले, अगर किसी भी तरह से आप पहले से ही एक स्क्रिप्ट के अंदर एक पासवर्ड स्टोर करने से बचने के लिए चीजों को बदल सकते हैं, तो आपको ऐसा करने का हर संभव प्रयास करना चाहिए। जेनी डी के जवाब में उस प्रभाव के लिए बहुत अच्छी सलाह है।
अन्यथा, पासवर्ड को अलग-अलग फ़ाइल में प्रतिबंधित अनुमतियों के साथ रखने का आपका विचार बहुत अधिक है। आप उदाहरण के लिए मुख्य स्क्रिप्ट से फ़ाइल स्रोत के लिए कर सकते हैं:
. /usr/local/etc/secret-password-hereआप मुख्य स्क्रिप्ट की अनुमतियों को भी सीमित कर सकते हैं, ताकि केवल अधिकृत व्यक्ति ही इसे निष्पादित कर सकें, लेकिन यह संभव है कि आप ऐसा करने के लिए सुझाव दें और केवल पासवर्ड को प्रतिबंधित फ़ाइल में संग्रहीत करें। इस तरह आप कोड के निरीक्षण की अनुमति दे सकते हैं (संवेदनशील रहस्य के बिना), संस्करण-नियंत्रण और स्क्रिप्ट के चारों ओर अधिक आसानी से कॉपी, आदि ...
/usr/local/etcएक प्रतीकात्मक लिंक हो सकता है /etc/local"। मैंने यह खो दिया। तो आप भी सही हैं, लेकिन यह एक MAY है इसलिए यह वैकल्पिक है। लेकिन हाँ, यह ज्यादा मायने नहीं रखता है, और व्यक्तिगत प्राथमिकता।
/etc/ लेकिन ऐसा नहीं है /usr/local/ (जो मुझे लगता है कि डिस्क क्रैश के बाद फिर से बनाया जा सकता है)
अन्य उत्तरों ने कैसे संबोधित किया है , लेकिन क्या मैं इस पर विचार करूंगा । क्या डेटाबेस अपने उपयोगकर्ताओं के लिए कनेक्ट कर रहे हैं की तरह, आप पहले से ही एक उपयुक्त तंत्र कि पहले से ही उन क्लाइंट प्रोग्राम द्वारा प्रयोग किया जाता है, जिसमें मामले उन का उपयोग सुनिश्चित करें (मैं सोच रहा हूँ हो सकता है पर निर्भर करता है ~/.mysqlrcया ~/.pgpass)।
यदि आप कई उपयोगकर्ताओं को साझा खाते का उपयोग करके विशिष्ट प्रश्नों को बनाने के लिए डेटाबेस तक पहुंचने की क्षमता दे रहे हैं, तो आपको संभवतः नहीं करना चाहिए। इसके बजाय, सुनिश्चित करें कि उनके पास डेटाबेस पर खाते हैं और उन खातों के पास उनकी आवश्यकता से अधिक अनुमति नहीं है (संभवतः इसे बहुत पढ़ा है, और बहुत कम लेखन पहुंच है)। यदि उन्हें कुछ तालिकाओं पर विशिष्ट प्रश्न बनाने की आवश्यकता होती है जो वे अन्यथा उपयोग नहीं कर सकते हैं, SECURTY DEFINERतो उन्हें ऐसा करने की अनुमति देने के साथ संग्रहीत कार्यविधियाँ प्रदान करें।
यदि उपरोक्त में से कोई भी आपको क्रेडेंशियल स्टोर करने की आवश्यकता से बचता है, तो यहां अन्य उत्तर पढ़ें।
किसी दुर्गम स्थान पर पासवर्ड छिपाने का आपका विचार परिस्थितियों के आधार पर ठीक हो सकता है।
यदि जानकारी अलग है, तो इसका मतलब है कि फ़ाइल का सरल संपादन, उदाहरण के लिए एक सहकर्मी के साथ कोड समीक्षा के दौरान यह दिखाने के लिए नहीं जा रहा है। लेकिन अपने खाते तक पहुंच वाले किसी को भी इस तरह की फ़ाइल आसानी से मिल सकती है। मैंने ~/.sshऐसे उद्देश्यों के लिए एक उपनिर्देशिका का उपयोग किया है, उस सरल कारण के लिए जो sshशिकायत करता है कि यदि उपयोग के अधिकार ~/.sshपर्याप्त रूप से प्रतिबंधित नहीं हैं।
हालांकि ऐसी अन्य चीजें हैं जो आप उपयोगकर्ता नाम और / या पासवर्ड की ऐसी झलक को रोकने के लिए कर सकते हैं।
Obfuscating : यदि आप नहीं चाहते कि कोई भी उपयोगकर्ता नाम या पासवर्ड पढ़े, जबकि आप एक स्क्रिप्ट संपादित करते हैं, तो आप इसे पाठ में रख सकते हैं, लेकिन सादे पाठ के रूप में नहीं, बल्कि बाधित। यदि ओफ़्फ़ुसेटेड संस्करण लंबे समय से किसी को देखकर उसके संस्मरण को रोक रहा है, तो यह भी नहीं जाना जा सकता है कि डिक्रिप्शन विधि और कुंजी सादे दृष्टि में हैं या नहीं। यह निश्चित रूप से आपके खाते तक पहुंच रखने वाले किसी व्यक्ति द्वारा अभी भी तुच्छ रूप से किया जाएगा।
GPG का उपयोग करना :
थोड़ा बेहतर है, लेकिन अभी भी आपके सिस्टम पर रूट उपयोगकर्ता के हमलों के खिलाफ पूर्ण प्रमाण नहीं है, अपनी फ़ाइल को उपयोगकर्ता में एन्क्रिप्ट करने के लिए उपयोगकर्ता नाम / पासवर्ड जोड़े को एन्क्रिप्ट करना है gpgऔर स्क्रिप्ट को फ़ाइल पर सामग्री को पुनः प्राप्त करना है (संभव है कि पासवर्ड के लिए आपको संकेत दिया जाए, यदि नहीं कैश की गई / समाप्त हो गई है)। मैं ggp-card का उपयोग करता हूं ताकि जब मैं अपना लैपटॉप इधर-उधर छोड़ दूं लेकिन कार्ड को बाहर खींच लूं, तो भी कोई पहुंच संभव नहीं है, भले ही पिन अभी भी कैश न हो। कम से कम अगर मैं कुछ मिनटों में 20 बार बात करता हूं तो मुझे केवल एक बार पिन प्रदान करना होगा।
सुरक्षा हमेशा सुविधा (स्थापना और उपयोग करना) से विपरीत रूप से संबंधित लगती है।
पासवर्ड को बैश स्क्रिप्ट में संग्रहीत करने का एक तरीका है, लेकिन आपको स्क्रिप्ट को एन्क्रिप्ट करना और उसमें बाधा डालना है ताकि कोई भी वास्तव में इसे पढ़ न सके या उस पर किसी भी प्रकार का डीबगर न चला सके, यह देखने के लिए कि यह क्या कर रहा है। किसी बैश / शेल स्क्रिप्ट को एन्क्रिप्ट करने और उसे बाधित करने के लिए, वास्तव में यह निष्पादन योग्य है, इसे यहां कॉपी और पेस्ट करने का प्रयास करें:
http://www.kinglazy.com/shell-script-encryption-kinglazy-shieldx.htm
उपरोक्त पृष्ठ पर, आपको बस अपनी स्क्रिप्ट सबमिट करनी है (आप अपने मन की शांति के लिए पहले एक नमूना स्क्रिप्ट प्रस्तुत कर सकते हैं)। आपके लिए एक जिप फाइल जेनरेट होगी। डाउनलोड लिंक पर राइट क्लिक करें और आपके द्वारा प्रदान किए गए URL को कॉपी करें। फिर, अपने UNIX बॉक्स पर जाएं और निम्न चरणों का पालन करें।
स्थापना:
wip लिंक-टू-द-ज़िप फ़ाइल
अनज़िप-नव-डाउनलोड-ज़िप-फ़ाइल
सीडी / tmp / KingLazySHIELD
./install.sh / var / tmp / KINGLAZY / SHIELDX- (आपकी स्क्रिप्ट-नाम) / घर / (आपका-उपयोगकर्ता नाम) -force
आपके लिए उपरोक्त इंस्टॉल कमांड क्या करेगी:
यह निर्देशिका / var / tmp / KINGLAZY / SHIELDX- (आपकी स्क्रिप्ट-नाम) में आपकी स्क्रिप्ट के एन्क्रिप्टेड संस्करण को स्थापित करेगा।
यह इस एन्क्रिप्टेड स्क्रिप्ट का लिंक देगा, जिसे आप / होम / (अपना-उपयोगकर्ता नाम) के प्रतिस्थापन में निर्दिष्ट करते हैं - इस तरह, यह आपको पूर्ण पथ टाइप किए बिना आसानी से स्क्रिप्ट तक पहुंचने की अनुमति देता है।
सुनिश्चित करता है कि कोई भी स्क्रिप्ट को संशोधित नहीं कर सकता है - एन्क्रिप्टेड स्क्रिप्ट को संशोधित करने का कोई भी प्रयास इसे अक्षम कर देगा ... जब तक कि उन प्रयासों को रोक या हटा नहीं दिया जाता है। यह तब भी आपको सूचित करने के लिए कॉन्फ़िगर किया जा सकता है जब भी कोई इसे चलाने के अलावा स्क्रिप्ट के साथ कुछ भी करने की कोशिश करता है ... यानी हैकिंग या संशोधन के प्रयास।
यह सुनिश्चित करता है कि कोई भी व्यक्ति इसकी प्रतियां न बना सके। कोई भी आपकी स्क्रिप्ट को एकांत स्थान पर कॉपी नहीं कर सकता है और यह कैसे काम करता है यह देखने के लिए इसके साथ पेंच लगाने की कोशिश करता है। स्क्रिप्ट की सभी प्रतियां मूल स्थान से लिंक होनी चाहिए जिसे आपने इंस्टॉल (चरण 4) के दौरान निर्दिष्ट किया था।
ध्यान दें:
मुझे विश्वास नहीं है कि यह इंटरैक्टिव स्क्रिप्ट के लिए काम करता है जो उपयोगकर्ता को प्रतिक्रिया के लिए संकेत देता है। मूल्यों को स्क्रिप्ट में हार्ड-कोड किया जाना चाहिए। एन्क्रिप्शन सुनिश्चित करता है कि कोई भी वास्तव में उन मूल्यों को नहीं देख सकता है, इसलिए आपको इसके बारे में चिंता करने की आवश्यकता नहीं है।
एक अन्य समाधान, सुरक्षा के संबंध में (मुझे भी लगता है कि क्रेडेंशियल्स को किसी अन्य फ़ाइल या डेटाबेस में रखना बेहतर है) पासवर्ड को gpg के साथ एन्क्रिप्ट करना और इसे स्क्रिप्ट में सम्मिलित करना है।
मैं एक पासवर्ड-कम gpg कुंजी जोड़ी का उपयोग करता हूं जिसे मैं एक USB में रखता हूं। (नोट: जब आप इस प्रमुख जोड़ी को निर्यात करते हैं - उपयोग नहीं करते हैं, तो उन्हें द्विआधारी प्रारूप में निर्यात करें)।
पहले अपना पासवर्ड एन्क्रिप्ट करें:
echo -n "pAssw0rd" | gpg --armor --no-default-keyring --keyring /media/usb/key.pub --recipient someone@mail.com --encryptकि जीएक्स एन्क्रिप्टेड पासवर्ड को जीडीपी आउटपुट में प्रिंट आउट किया जाएगा। पूरे संदेश की प्रतिलिपि बनाएँ और इसे स्क्रिप्ट में जोड़ें:
password=$(gpg --batch --quiet --no-default-keyring --secret-keyring /media/usb/key.priv --decrypt <<EOF
-----BEGIN PGP MESSAGE-----
hQEMA0CjbyauRLJ8AQgAkZT5gK8TrdH6cZEy+Ufl0PObGZJ1YEbshacZb88RlRB9
h2z+s/Bso5HQxNd5tzkwulvhmoGu6K6hpMXM3mbYl07jHF4qr+oWijDkdjHBVcn5
0mkpYO1riUf0HXIYnvCZq/4k/ajGZRm8EdDy2JIWuwiidQ18irp07UUNO+AB9mq8
5VXUjUN3tLTexg4sLZDKFYGRi4fyVrYKGsi0i5AEHKwn5SmTb3f1pa5yXbv68eYE
lCVfy51rBbG87UTycZ3gFQjf1UkNVbp0WV+RPEM9JR7dgR+9I8bKCuKLFLnGaqvc
beA3A6eMpzXQqsAg6GGo3PW6fMHqe1ZCvidi6e4a/dJDAbHq0XWp93qcwygnWeQW
Ozr1hr5mCa+QkUSymxiUrRncRhyqSP0ok5j4rjwSJu9vmHTEUapiyQMQaEIF2e2S
/NIWGg==
=uriR
-----END PGP MESSAGE-----
EOF)इस तरह से अगर सिस्टम में usb माउंट हो जाए तो पासवर्ड को डिक्रिप्ट किया जा सकता है। बेशक आप सिस्टम में चाबियाँ आयात कर सकते हैं (कम सुरक्षित, या कोई सुरक्षा बिल्कुल नहीं) या आप पासवर्ड के साथ निजी कुंजी की रक्षा कर सकते हैं (इसलिए यह स्वचालित नहीं हो सकता है)।
#!/bin/bash
unset username
unset password
unset dbname
echo -n "username:"
read username
echo -n "dbname:"
read dbname
prompt="password:"
while IFS= read -p "$prompt" -r -s -n 1 char
do
if [[ $char == $'\0' ]]
then
break
fi
prompt='*'
password+="$char"
# read -s -p "Enter Password: " pswd
# echo -e "\nYour password is: " $pswd
doneमेरा मानना है कि आपको कभी भी पासवर्ड स्टोर नहीं करना चाहिए। मैं इसके लिए एक भी अच्छा कारण नहीं सोच सकता। बल्कि, आपको उस पासवर्ड का नमकीन हैश स्टोर करना चाहिए - कुछ स्ट्रिंग जो मूल फ़ंक्शन द्वारा इनपुट के रूप में पारित किए जाने पर किसी फ़ंक्शन द्वारा मज़बूती से निर्मित होती हैं, लेकिन कभी भी पासवर्ड नहीं ।