रूट का उपयोग करने के बजाय उपयोगकर्ता को sudo विशेषाधिकार निर्दिष्ट करने के वास्तविक लाभ क्या हैं?


25

मैं सर्वर प्रशासन के लिए काफी नया हूं, और मैंने कई साइटें देखी हैं जो रूट उपयोगकर्ता द्वारा बनाए गए उपयोगकर्ता को sudo विशेषाधिकारों को निर्दिष्ट करने और रूट उपयोगकर्ता को सुरक्षा बढ़ाने के लिए एक पागलपन भरा पासवर्ड देने की सिफारिश करते हैं।

यदि नव निर्मित उपयोगकर्ता रूट उपयोगकर्ता के रूप में समान कार्य कर सकता है, लेकिन ऐसा करने का वास्तविक लाभ क्या है?


7
Sudoer सब कुछ रूट नहीं कर सकता है, केवल वही रूट क्या sudoers को sudo की अनुमति देता है, और sudoer को अभी भी कमांड को sudo करना है। अंत में, अपने स्वयं के उपयोगकर्ता खाते के रूप में सूडो चीजों को सूडो करता है, पहला अर्थ है कि उन्हें रूट के रूप में लॉग इन करने की आवश्यकता नहीं है, और दूसरा आपको यह देखने की अनुमति देता है कि कौन कुछ सूद करता है।
कीथ्स

जवाबों:


48

sudoरूट पासवर्ड को सौंपने के लिए कई फायदे हैं। किसी विशेष क्रम में नहीं:

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

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

  • आप sudo LDAP कॉन्फ़िगरेशन का समर्थन केंद्रीय रूप से प्रबंधित कर सकते हैं , जिसका अर्थ है कि आपकी कंपनी का प्रत्येक सिस्टम केंद्रीय LDAP सर्वर को देखने के लिए यह निर्धारित कर सकता है कि किसको क्या करने की अनुमति है।
    किसी को अधिकृत (या डी-अधिकृत) करने की आवश्यकता है? LDAP में sudoers कॉन्फ़िगरेशन बदलें और आपके सभी सिस्टम एक साथ अपडेट किए जाते हैं।

  • एक ऑडिट ट्रेल
    है जिसमें उन उपयोगकर्ताओं के अपवाद के साथ, जो या कुछ के बराबर करने की अनुमति है sudo su -, एक ऑडिट ट्रेल का उत्पादन करेगा जिसमें उपयोगकर्ता इन कमांडों को चलाता है। (यह उन लोगों की एक सूची भी तैयार करेगा, जिन्होंने खुद को एक असंबद्ध जड़ खोल दिया था, इसलिए आप उन पर अपनी उंगली को इंगित कर सकते हैं और अस्वीकृति में उनका आनंद ले सकते हैं।)sudo shsudo

  • sudoबस रूट की तुलना में अधिक के लिए अच्छा है पर हर कोई ध्यान केंद्रित sudoकरने के लिए एक मार्ग के रूप कर के रूप में सामान सु peruser, लेकिन यह नहीं है सभी के लिए यह अच्छा है।
    कहते हैं कि ऐलिस एक विशेष सॉफ्टवेयर बिल्ड के लिए जिम्मेदार है, लेकिन बॉब को बिल्ड स्क्रिप्ट को चलाने में सक्षम होना चाहिए। आप बॉब को सुडोर्स में एक प्रविष्टि दे सकते हैं जो उसे ऐलिस के उपयोगकर्ता के रूप में बिल्ड स्क्रिप्ट चलाने की सुविधा देता है। (हां, निश्चित रूप से, इस विशेष मामले से निपटने के लिए बहुत बेहतर तरीके हैं, लेकिन इसका सिद्धांत Let user A run a program as user Bउपयोगी हो सकता है ...)।
    आप सभी समान ऑडिट-ट्रेल लाभ भी प्राप्त करते हैं जो मैंने ऊपर उल्लेख किया था जब आप ऐसा करते हैं ...


1
बहुत उपयोगी उत्तर - अगर मुझे पता है (और मेरा मतलब 100% निश्चितता के साथ) है कि मैं केवल एक ही सर्वर का प्रबंधन करने वाला हूं, लेकिन क्या आप सूडो विशेषाधिकारों को किसी अन्य उपयोगकर्ता को निर्दिष्ट करने के लिए बहुत अधिक लाभ देखते हैं (जो स्वयं वैसे भी होंगे) खुद को कुछ खराब करने से रोकने से बाहर?
JM4

3
@ JM4 संगति, और भविष्य में एक दिन के लिए अच्छा अभ्यास जब आप बड़े वातावरण में काम कर रहे हों। एक व्यावहारिक दृष्टिकोण से, आपको कभी भी सीधे रूट के रूप में लॉग इन नहीं करना चाहिए जब तक कि आप भौतिक कंसोल पर कुछ ठीक नहीं कर रहे हैं जिसे रोयली रूप से लगाया गया है, इसलिए sudoबनाम suएक शैक्षणिक अंतर है - आपको एक घेरा या दूसरे के माध्यम से कूदना होगा। उपयोग sudoकरने से आपको व्यावहारिक रूप से कम से कम विशेषाधिकार (मेरा अंतिम बिंदु) के सिद्धांत का उपयोग करने का मौका मिलता है और यह हमेशा गंभीरता से विचार करने के लिए कुछ है।
voretaq7

2
इसके अलावा, अपने sudoers फ़ाइल को संपादित करने के लिए visudo का उपयोग करें।
जस्टिन डियरिंग

3
ध्यान दें कि कई इंटरैक्टिव कमांड्स उपयोगकर्ताओं को ऑडिट ट्रेल को बायपास करने की अनुमति देंगे। उदाहरण के लिए, कोई भी उपयोगकर्ता जो एक बार vi के अंदर हो sudo viसकता है :! bash
डायट्रीच एप्प

4
@DietrichEpp NOEXECटैग उस मामले में मदद करता है।
शेन मैडेन

17

प्राथमिक अंतर यह है कि उपयोगकर्ता अपने पासवर्ड sudoका उपयोग करने के लिए प्रमाणित करते हैं, जबकि रूट पासवर्ड के साथ या सीधे लॉगिन का उपयोग किया जाता है।su

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

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


1
आपके सहयोग के लिए धन्यवाद। मुझे आपके बिंदु से लाभ दिखाई देता है, लेकिन मैंने वास्तव में एक मूल उपयोगकर्ता को मूल उपयोगकर्ता के रूप में देखा, क्योंकि मैंने अपने सर्वर पर ssh से अक्षम रूट उपयोगकर्ता लॉगिन को दिया है।
JM4

4

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


2

हां वास्तव में - एक नियंत्रण और लॉगिंग दृष्टिकोण से सुडो ज्यादा बेहतर है।

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

दूसरी ओर सूडो मूल उपयोगकर्ता के रूप में बहुत अधिक सब कुछ लॉग करता है।


0

Sudo का उपयोग करना दुर्भावनापूर्ण उपयोगकर्ता के लिए सिस्टम तक पहुँच प्राप्त करना कठिन बनाता है। जब एक अनलॉक रूट खाता होता है, तो एक दुर्भावनापूर्ण उपयोगकर्ता को उस खाते का उपयोगकर्ता नाम पता होता है जिसे वह शुरू करने से पहले दरार करना चाहता है। जब रूट खाता लॉक हो जाता है, तो उपयोगकर्ता को सिस्टम में टूटने के लिए उपयोगकर्ता नाम और पासवर्ड निर्धारित करना होगा।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.