2008-10-16 8 views
16

कैसे प्रबंधित करते हैं हमारी प्रशासन टीम में सभी के पास सभी क्लाइंट सर्वरों के लिए रूट पासवर्ड हैं। लेकिन अगर टीम के सदस्यों में से कोई हमारे साथ काम नहीं कर रहा है तो हमें क्या करना चाहिए? उसके पास अभी भी हमारे पासवर्ड हैं और हमें हर बार उन्हें बदलना होगा, हर बार जब कोई हमें छोड़ देता है।आप सर्वर के रूट पासवर्ड

अब हम पासवर्ड के बजाय एसएसएच कुंजी का उपयोग कर रहे हैं, लेकिन अगर हमें एसएसएच के अलावा कुछ और उपयोग करना है तो यह सहायक नहीं है।

उत्तर

23

मेरे द्वारा चलाए जाने वाले सिस्टम में sudo-केवल नीति है। यानी, रूट पासवर्ड * (अक्षम) है, और लोगों को रूट पहुंच प्राप्त करने के लिए सूडो का उपयोग करना होगा। फिर आप लोगों की पहुंच को अनुदान/रद्द करने के लिए अपनी sudoers फ़ाइल संपादित कर सकते हैं। यह बहुत दानेदार है, और इसमें बहुत सी कॉन्फ़िगरेशन क्षमता है --- लेकिन समझदार डिफ़ॉल्ट हैं, इसलिए इसे स्थापित करने में आपको लंबा समय नहीं लगेगा।

+1

आप अन्य यूआईडी/गीड 0 उपयोगकर्ताओं के लिए कितनी बार चेक करते हैं और रूट पासवर्ड के लिए अभी भी अक्षम किया जा रहा है? –

+1

अच्छे ऑपरेटिंग सिस्टम (उदा। ओपनबीएसडी) पर, एक दैनिक ईमेल आपको बताता है कि विभिन्न महत्वपूर्ण फाइलों जैसे कि पासवर्ड डेटाबेस (साथ ही ऑडिटिंग स्क्रिप्ट स्वयं) में क्या बदलाव किए गए हैं। :-) –

+0

वह ऑडिटिंग स्क्रिप्ट आपको किसी भी नए सेटूइड प्रोग्राम के लिए भी अलर्ट करता है। –

4

हालांकि क्रिस की तरह ही सूडो का उपयोग करना एक अच्छा विचार है, जैसे कि आपके सिस्टम के आकार के आधार पर एक एलडीएपी दृष्टिकोण भी सहायक हो सकता है। हम उस फ़ाइल द्वारा पूरक हैं जिसमें सभी रूट पासवर्ड शामिल हैं लेकिन रूट पासवर्ड वास्तव में लंबे और अनौपचारिक हैं। हालांकि इसे सुरक्षा दोष माना जा सकता है, लेकिन अगर हमें ldap सर्वर डाउन हो जाता है तो यह अभी भी लॉग इन करने की अनुमति देता है।

+0

मुझे इस पर उद्धरण न दें, लेकिन मुझे याद है कि सुडौर्स एलडीएपी में भी संग्रहीत किए जा सकते हैं, जो कि बहुत अच्छा है जब आपके पास कई सर्वर हैं जिन्हें केंद्रीय रूप से प्रबंधित किया जाना है। :-) +1 –

0

आप अपने प्रमाण पत्र के माध्यम से ssh पहुँच है, तो आप ssh के माध्यम से लॉग इन करें और passwd या sudo passwd के माध्यम से root पासवर्ड बदलने के लिए जब आप कुछ और ही है कि पासवर्ड की आवश्यकता है क्या करने की जरूरत नहीं कर सकते?

+0

यदि आपके पास रूट पहुंच है तो आप रूट पासवर्ड बदल सकते हैं, लेकिन जिन उपयोगकर्ताओं के पास प्रमाण पत्र के माध्यम से रूट पहुंच है, वे रूट पासवर्ड को नहीं बदलना चाहते हैं, कई कारणों से – bmwael

+0

पिछली बार मैंने कोशिश की, passwd रूट के लिए संकेत दिया गया रूट रूट के रूप में पहले से चलने पर भी पुराना रूट पासवर्ड, लेकिन फिर रूट के रूप में कोई सुरक्षा सीधे/etc/छाया संपादित नहीं कर सकती है। – Joshua

0

हम सूडो केवल नीति का उपयोग करते हैं जहां मैं काम करता हूं, लेकिन रूट पासवर्ड अभी भी रखे जाते हैं। रूट पासवर्ड केवल कुछ चुनिंदा कर्मचारियों के लिए उपलब्ध हैं। हमारे पास पासवर्ड मैनेजर प्रो नामक एक प्रोग्राम है जो हमारे सभी पासवर्ड स्टोर करता है, और पासवर्ड ऑडिट भी प्रदान कर सकता है। यह हमें वापस जाने और देखने के लिए अनुमति देता है कि कौन से पासवर्ड एक्सेस किए गए हैं। इस प्रकार, हम केवल उन पासवर्ड को बदलने में सक्षम हैं जिन्हें वास्तव में बदलने की आवश्यकता है।

3

सूडो नीति के अलावा, जो शायद बेहतर है, कोई कारण नहीं है कि प्रत्येक व्यवस्थापक के पास यूआईडी 0 के साथ अपना खाता नहीं हो सकता है, लेकिन अलग-अलग नाम और अलग-अलग होम निर्देशिका के साथ अलग-अलग नाम दिया गया है। जब वे चले गए तो बस अपने खाते को हटा दें।

1

हमने अभी भी प्रत्येक मशीन पर रूट पासवर्ड को बदलने में वास्तव में आसान बना दिया है, इसलिए जब लोग चले गए तो हमने अभी स्क्रिप्ट चलाई। मुझे बहुत समझदार नहीं पता लेकिन यह काम किया। मेरे समय से पहले, कंपनी के हर किसी के पास सभी सर्वर पर रूट तक पहुंच थी। सौभाग्य से हम उस से दूर चले गए।

1

आम तौर पर, अगर कोई हमारी टीम छोड़ देता है, तो हम रूट पासवर्ड बदलना परेशान नहीं करते हैं। या तो उन्होंने कंपनी छोड़ दी (और मशीनों तक पहुंचने का कोई तरीका नहीं है क्योंकि उनके वीपीएन को निरस्त कर दिया गया है, क्योंकि इमारत में उनकी बैज पहुंच है, और नेटवर्क पर उनकी वायरलेस पहुंच है), या वे कंपनी के अंदर किसी अन्य विभाग में हैं और हमारे पर्यावरण के साथ पेंच नहीं करने के लिए पेशेवरता है।

क्या यह एक सुरक्षा छेद है? शायद। लेकिन, वास्तव में, अगर वे हमारे पर्यावरण के साथ पेंच करना चाहते थे, तो वे आगे बढ़ने से पहले ऐसा करते थे।

अभी तक, जो भी टीम हमारी टीमों तक पहुंच हासिल करना चाहता है उसे छोड़कर किसी ने भी अनुमति मांगी है, भले ही वे अनुमति के बिना हो सकें। मुझे काम करने की हमारी क्षमता में बाधा डालने का कोई कारण नहीं दिखता है, यानी, किसी और को आगे बढ़ने पर विश्वास करने का कोई कारण अलग-अलग नहीं होगा।

1

उचित मजबूत रूट पासवर्ड। प्रत्येक बॉक्स पर अलग। कोई रिमोट रूट लॉग इन नहीं, और लॉग इन के लिए कोई पासवर्ड नहीं, केवल कुंजी।

6

मैं सामान्य रूप से निम्नलिखित सुझाव है:

  1. एक खाली रूट पासवर्ड का प्रयोग करें। 'जड़: सभी:
  2. अक्षम टेलनेट
  3. कोई रूट लॉगिन (या रूट लॉगिन केवल सार्वजनिक कुंजी द्वारा)
  4. अक्षम सु/etc/suauth के शीर्ष करने के लिए इस जोड़कर रूट करने के लिए सेट ssh इनकार '
  5. कंसोल पर रूट लॉगिन केवल (TTY1-tty8)
  6. सामान्य रूट पहुँच के लिए उपयोग sudo

अब तो, इस सेटिंग के साथ, सभी उपयोगकर्ताओं sudo दूरदराज के व्यवस्थापक के लिए उपयोग करना चाहिए, के लिए सुरक्षित tty सक्षम करें लेकिन जब सिस्टम गंभीरता से गड़बड़ हो जाता है, तो वहां नहीं होता है कंसोल अनलॉक करने के लिए रूट पासवर्ड के लिए शिकार।

संपादित करें: अन्य सिस्टम प्रशासन उपकरण जो अपने स्वयं के लॉगिन प्रदान करते हैं उन्हें समायोजन की भी आवश्यकता होगी।

+1

यह वास्तव में एक अच्छा सेटअप है। मुझे भौतिक कंसोल पर पीडब्ल्यू-कम लॉगिन का विचार पसंद है। हालांकि, आपको यह सुनिश्चित करना होगा कि प्रमाणीकरण (वेबमाइन इत्यादि) के लिए सिस्टम खातों का उपयोग करने वाला कोई भी सॉफ्टवेयर भी अनुकूलित किया गया हो। – sleske

+0

धन्यवाद, और यह इंगित करने के लिए धन्यवाद कि अन्य सॉफ़्टवेयर कभी-कभी अप्रत्याशित पथों के माध्यम से लॉगिन की अनुमति देता है। – Joshua

0

एसएसएच कुंजी कोई वास्तविक विकल्प नहीं है।

कई सर्वरों आप अपने स्वयं के समाधान को लागू करने के लिए यदि आप हर सर्वर पर एक ही फाइल नहीं करना चाहते हैं पर कई authorized_keys फ़ाइलों के प्रबंधन के लिए

। या तो अपने उपकरण के माध्यम से, या कुछ विन्यास प्रबंधन समाधान जैसे कठपुतली, उत्तरदायी या उस तरह कुछ।

bash में लूप के लिए अन्य या कुछ clush कार्रवाई पर्याप्त होगी।

SSH लॉगिन के अलावा कुछ भी:
सेवाओं आपको लगता है कि कर रहे हैं के लिए लॉग इन आधारित चलाने के लिए, एक केंद्रीय बैकएंड के साथ प्रमाणीकरण के कुछ प्रकार का उपयोग करें। ध्यान रखें कि यदि कोई बैकएंड अनुपलब्ध है तो कोई भी काम नहीं करेगा!

सेवा क्लस्टर चलाएं। सुपर-डुपर-सेवा बैकडोर खाते के साथ हैक्स न करें, हमेशा कुछ ब्रेक होने पर पहुंच प्राप्त करें (जैसे कि गलत पहुंच के कारण व्यवस्थापक पहुंच टूटा हुआ है)। कोई फर्क नहीं पड़ता कि आप इस खाते को प्रभावित करने वाले एक्सेस या कॉन्फ़िगरेशन परिवर्तनों की निगरानी कैसे करते हैं, यह 'बस खराब' (टीएम) है।

इस पिछवाड़े के अधिकार को पाने के बजाय, आप एप्लिकेशन को क्लस्टर भी कर सकते हैं, या कम से कम एक अतिरिक्त सिस्टम समय पर सेटअप को मिरर कर रहा है यदि मुख्य बॉक्स मर जाता है, जिसे रूटिंग में आसानी से सक्रिय किया जा सकता है नेटवर्क में यदि यह बहुत जटिल लगता है, तो आपका व्यवसाय या तो बहुत छोटा है और आप आधे दिन से दो दिन डाउनटाइम तक रह सकते हैं। या आप ज्ञान की कमी के कारण वास्तव में क्लस्टर से नफरत करते हैं और केवल गलत चीजों पर बचत कर रहे हैं।

सामान्य में: यदि आप सॉफ़्टवेयर का उपयोग किसी प्रकार की सक्रिय निर्देशिका या एलडीएपी एकीकरण के साथ अनुपयोगी करते हैं तो आपको शार्क को कूदना होगा और इन्हें मैन्युअल रूप से पासवर्ड बदलना होगा।

इसके अलावा एक समर्पित पासवर्ड प्रबंधन डेटाबेस जिसे केवल कुछ चयनित कुछ लोगों द्वारा ही पहुंचा जा सकता है, और केवल अन्य सभी के लिए पढ़ा जा सकता है, यह बहुत अच्छा है। एक्सेल फाइलों से परेशान न हों, इनका उचित अधिकार प्रबंधन की कमी है। .csv फ़ाइलों पर संस्करण नियंत्रण के साथ काम करना वास्तव में एक निश्चित सीमा के बाद इसे काट नहीं देता है।