रूट के रूप में काम कर रहे कई लिनक्स sysadmins


40

हमारी टीम में हमारे पास तीन सीज़न वाले Linux sysadmins हैं जो कुछ दर्जन डेबियन सर्वरों को संचालित करते हैं। पहले हम सभी SSH सार्वजनिक कुंजी प्रमाणीकरण का उपयोग कर रूट के रूप में काम कर चुके हैं। लेकिन हमने इस बात पर चर्चा की कि उस परिदृश्य के लिए सबसे अच्छा अभ्यास क्या है और किसी भी बात पर सहमत नहीं हो सकते।

हर किसी की SSH सार्वजनिक कुंजी ~ रूट / .ssh / अधिकृत_keys2 में डाल दी जाती है

  • लाभ: उपयोग करने में आसान, एसएसएच एजेंट अग्रेषण आसानी से काम करता है, थोड़ा उपरि
  • नुकसान: लापता ऑडिटिंग (आप कभी नहीं जानते कि किस "रूट" ने एक बदलाव किया), दुर्घटनाओं की संभावना अधिक है

व्यक्तिगत खातों और sudo का उपयोग करना

इस तरह हम SSH सार्वजनिक कुंजी का उपयोग कर व्यक्तिगत खातों के साथ लॉगिन करेंगे और रूट अनुमतियों के साथ एकल कार्य करने के लिए sudo का उपयोग करेंगे । इसके अलावा हम खुद को "प्रशंसा" समूह दे सकते हैं जो हमें लॉग फाइल को देखने की अनुमति देता है।

  • फायदा: अच्छा ऑडिटिंग, सुडो हमें बहुत आसानी से बेवकूफ बनाने से रोकता है
  • नुकसान: एसएसएच एजेंट आगे को तोड़ता है, यह एक परेशानी है क्योंकि मुश्किल से कुछ भी गैर-रूट के रूप में किया जा सकता है

कई यूआईडी 0 उपयोगकर्ताओं का उपयोग करना

यह एक बहुत ही अनोखा प्रस्ताव है जिसमें से एक सिस्मडिन्स है। वह यूआईडी 0 वाले तीन उपयोगकर्ताओं को / etc / passwd बनाने का सुझाव देता है, लेकिन अलग-अलग लॉगिन नाम। उनका दावा है कि यह वास्तव में निषिद्ध नहीं है और सभी को UID 0 होने की अनुमति देता है, लेकिन फिर भी ऑडिट करने में सक्षम है।

  • लाभ: SSH एजेंट अग्रेषण कार्य करता है, ऑडिटिंग काम कर सकता है (अप्रयुक्त), कोई sudo परेशानी नहीं
  • नुकसान: बहुत गंदा लगता है - यह एक अनुमति के रूप में कहीं भी प्रलेखित नहीं मिल सका

आप क्या सुझाव देंगे?


2
आपके "के बारे में यह एक अनुमत तरीके के रूप में कहीं भी प्रलेखित नहीं पाया जा सकता है" बयान: मैनुअल पेज -oमें ध्वज को देखो useradd। यह ध्वज वहाँ कई उपयोगकर्ताओं को एक ही यूआईडी साझा करने की अनुमति देने के लिए है।
जूलियाग्रे

6
क्या आप समझा सकते हैं कि दूसरे विकल्प में "एसएसएच एजेंट फॉरवर्डिंग ब्रेक" से आपका क्या मतलब है? हम इसे अपने काम में उपयोग करते हैं और ssh एजेंट अग्रेषण ठीक काम करता है।
पैट्रिक

4
आपको sudo के बजाय अपने गैर-रूट खाते से ssh बाहर करना चाहिए।
रैंडम 832

4
सुडो विधि का एक और परिणाम: आप रूट के रूप में अब एससीपी / एफ़टीपी नहीं कर सकते। किसी भी फाइल ट्रांसफर को पहले व्यक्ति के होम डायरेक्टरी में ले जाना होगा और फिर टर्मिनल में कॉपी करना होगा। यह परिप्रेक्ष्य के आधार पर एक फायदा और नुकसान है।
user606723

1
कठपुतली / रसोइया / ansible-type सिस्टम पर विचार क्यों नहीं किया जा रहा है?
एलेक्स होल्स्ट

जवाबों:


64

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

एजेंट अग्रेषण वास्तव में कैसे टूटता है?

इसके अलावा, अगर यह इस तरह के झंझट का उपयोग sudoहर कार्य के सामने कर रहा है, तो आप एक sudo शेल को इनवॉइस sudo -sया रूट शेल के साथ स्विच कर सकते हैंsudo su -


10
SSH द्वारा रूट एक्सेस को पूरी तरह से डिसेबल करने के बजाय, मैं SSH द्वारा रूट एक्सेस की कुंजी बनाने की सलाह देता हूं, एक बहुत मजबूत कीफ्रेज़ के साथ एक कुंजी बनाना और इसे केवल आपातकालीन उपयोग के लिए बंद रखना। यदि आपके पास स्थायी कंसोल एक्सेस है तो यह कम उपयोगी है, लेकिन यदि आप ऐसा नहीं करते हैं, तो यह बहुत उपयोगी हो सकता है।
एइटबिटोनी

17
मैं सुरक्षा उद्देश्यों के लिए SSH पर रूट लॉगिन को अक्षम करने की सलाह देता हूं। यदि आपको वास्तव में रूट के रूप में लॉग इन करने की आवश्यकता है, तो एक गैर-रूट उपयोगकर्ता और su के रूप में लॉग इन करें।
ताज़

+1 .. मैं "दूसरा विकल्प सबसे अच्छा है" कहने से आगे जाऊंगा। मैं यह केवल उचित विकल्प होगा। विकल्प एक और तीन बाहरी हमलों और गलतियों से सिस्टम की सुरक्षा को काफी कम कर देते हैं। इसके अलावा, # 2 है कि सिस्टम को मुख्य रूप से उपयोग करने के लिए कैसे डिज़ाइन किया गया था ।
बेन ली

2
कृपया, विस्तार से बताएं sudo -s। क्या मैं यह समझने में सही हूं कि सादे रूट लॉगिन की तुलना में अतिरिक्त लॉग प्रविष्टि के अलावा रूट के रूप में sudo -iउपयोग करने su -या मूल रूप से लॉगिंग में कोई अंतर नहीं है ? अगर यह सच है, तो यह सादे रूट लॉगिन से कैसे और क्यों बेहतर है?
PF4Public

9

3rd सुझाई गई रणनीति के संबंध में useradd -o -u userXXX, @jlliagre द्वारा सुझाए गए विकल्पों के अलावा, मैं एक ही यूआईडी के रूप में कई उपयोगकर्ताओं को चलाने से परिचित नहीं हूं। (इसलिए यदि आप इसके साथ आगे बढ़ते हैं, तो यदि आप किसी भी मुद्दे (या सक्सेज) के साथ पोस्ट को अपडेट कर सकते हैं तो मुझे दिलचस्पी होगी ...)

मुझे लगता है कि पहले विकल्प के बारे में मेरा पहला अवलोकन "हर किसी की SSH सार्वजनिक कुंजी ~ रूट / .ssh / अधिकृत_keys2" में डाल दी जाती है, यह है कि जब तक आप बिल्कुल किसी अन्य सिस्टम पर काम नहीं करेंगे;

  1. फिर कम से कम कुछ समय के लिए , आपको उपयोगकर्ता खातों और के साथ काम करना होगाsudo

दूसरा अवलोकन यह होगा कि यदि आप उन प्रणालियों पर काम करते हैं जो HIPAA, PCI-DSS अनुपालन, या CAPP और EAL जैसे सामानों पर काम करते हैं, तो आपको sudo के मुद्दों पर काम करना होगा क्योंकि;

  1. यह गैर-रूट व्यक्तिगत उपयोगकर्ता खाते प्रदान करने के लिए एक उद्योग मानक है, जिसे आमतौर पर कुछ केंद्रीकृत उपयोगकर्ता डेटाबेस का उपयोग करके ऑडिट, अक्षम, समाप्त, आदि किया जा सकता है।

इसलिए; व्यक्तिगत खातों और sudo का उपयोग करना

यह दुर्भाग्यपूर्ण है कि एक sysadmin के रूप में, लगभग सभी चीजें जो आपको एक रिमोट मशीन पर करने की आवश्यकता होगी, कुछ ऊंचे अनुमतियों की आवश्यकता होगी, हालांकि यह कष्टप्रद है कि आपके पास रहते समय अधिकांश SSH आधारित टूल और उपयोगिताओं का भंडाफोड़ हो जाता है। sudo

इसलिए मैं कुछ तरकीबों से गुजर सकता हूं जिनका उपयोग मैं काम करने के लिए करता हूं sudo। पहली समस्या यह है कि यदि रूट लॉगिन का उपयोग करके ब्लॉक किया गया है PermitRootLogin=noया आपके पास ssh कुंजी का उपयोग करके रूट नहीं है, तो यह SCP फ़ाइलों को PITA से कुछ बनाता है।

समस्या 1 : आप दूरस्थ पक्ष से फ़ाइलों को स्कैन करना चाहते हैं, लेकिन उन्हें रूट एक्सेस की आवश्यकता होती है, हालाँकि आप सीधे रूट के रूप में दूरस्थ बॉक्स में प्रवेश नहीं कर सकते हैं।

बोरिंग सॉल्यूशन : फाइलों को होम डायरेक्टरी, चाउन और स्कैप डाउन पर कॉपी करें।

ssh userXXX@remotesystem, sudo su -आदि, cp /etc/somefilesसे /home/userXXX/somefiles, chown -R userXXX /home/userXXX/somefilesदूरस्थ से फ़ाइलों को पुनः प्राप्त करने के लिए scp का उपयोग करें।

वास्तव में बहुत उबाऊ।

कम बोरिंग समाधान : sftp -s sftp_serverध्वज का समर्थन करता है , इसलिए आप निम्न की तरह कुछ कर सकते हैं (यदि आपने पासवर्ड-कम sudo कॉन्फ़िगर किया है /etc/sudoers);

sftp  -s '/usr/bin/sudo /usr/libexec/openssh/sftp-server' \
userXXX@remotehost:/etc/resolv.conf 

(आप sshfs के साथ भी इस हैक-अराउंड का उपयोग कर सकते हैं, लेकिन मुझे यकीन नहीं है कि इसकी सिफारिश की गई है ... ;-)

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

पोर्ट फ़ॉरवर्ड निंजा विधि :

दूरस्थ होस्ट में लॉग इन करें, लेकिन निर्दिष्ट करें कि रिमोट पोर्ट 3022 (कुछ भी मुफ्त हो सकता है, और एडिंस के लिए गैर-आरक्षित, अर्थात> 1024) को स्थानीय पक्ष में 22 पोर्ट पर वापस भेजा जाना है।

 [localuser@localmachine ~]$ ssh userXXX@remotehost -R 3022:localhost:22
Last login: Mon May 21 05:46:07 2012 from 123.123.123.123
------------------------------------------------------------------------
This is a private system; blah blah blah
------------------------------------------------------------------------

सामान्य फैशन में जड़ें प्राप्त करें ...

-bash-3.2$ sudo su -
[root@remotehost ~]# 

अब आप फ़ाइलों की इंटरमीडिएट कॉपी बनाने के उबाऊ उबाऊ कदम से बचने के लिए दूसरी दिशा में फ़ाइलों को स्कैन कर सकते हैं;

[root@remotehost ~]#  scp -o NoHostAuthenticationForLocalhost=yes \
 -P3022 /etc/resolv.conf localuser@localhost:~
localuser@localhost's password: 
resolv.conf                                 100%  
[root@remotehost ~]#  

 

 

समस्या 2: SSH एजेंट अग्रेषण : यदि आप रूट प्रोफ़ाइल को लोड करते हैं, उदाहरण के लिए एक लॉगिन शेल निर्दिष्ट करके, SSH एजेंट के लिए आवश्यक पर्यावरण चर जैसे SSH_AUTH_SOCKरीसेट किए जाते हैं, इसलिए SSH एजेंट अग्रेषण "के तहत" टूट गया है sudo su -

आधा बेक्ड उत्तर :

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

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

वैसे भी, आप सक्षम कर सकते हैं कि आपका उपयोगकर्ता अपने ईएनवी वैरिएबल को संरक्षित कर सकता है, सूडॉयर में निम्नलिखित सेट करके;

 Defaults:userXXX    !env_reset

यह आपको ऐसा करने के लिए गंदा संकर लॉगिन वातावरण बनाने के लिए अनुमति देता है;

सामान्य के रूप में लॉगिन करें;

[localuser@localmachine ~]$ ssh userXXX@remotehost 
Last login: Mon May 21 12:33:12 2012 from 123.123.123.123
------------------------------------------------------------------------
This is a private system; blah blah blah
------------------------------------------------------------------------
-bash-3.2$ env | grep SSH_AUTH
SSH_AUTH_SOCK=/tmp/ssh-qwO715/agent.1971

बैश शेल बनाएं, जो चलता है /root/.profileऔर /root/.bashrc। लेकिन संरक्षित करता हैSSH_AUTH_SOCK

-bash-3.2$ sudo -E bash -l

तो इस शेल में रूट अनुमतियां हैं, और रूट $PATH(लेकिन एक बोर्क्ड होम डायरेक्टरी ...)

bash-3.2# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=user_u:system_r:unconfined_t
bash-3.2# echo $PATH
/usr/kerberos/sbin:/usr/local/sbin:/usr/sbin:/sbin:/home/xtrabm/xtrabackup-manager:/usr/kerberos/bin:/opt/admin/bin:/usr/local/bin:/bin:/usr/bin:/opt/mx/bin

लेकिन आप उस मंगलाचरण का उपयोग उन चीजों को करने के लिए कर सकते हैं जिनके लिए सुदूर सूडो रूट की आवश्यकता होती है, लेकिन एसएसएच एजेंट भी ऐसा ही करते हैं;

bash-3.2# scp /root/.ssh/authorized_keys ssh-agent-user@some-other-remote-host:~
/root/.ssh/authorized_keys              100%  126     0.1KB/s   00:00    
bash-3.2# 

1
मुझे हैक पसंद है।
sjbotha

2

तीसरा विकल्प आदर्श दिखता है - लेकिन क्या आपने वास्तव में यह देखने की कोशिश की है कि क्या हो रहा है? जब आप प्रमाणीकरण चरण में अतिरिक्त उपयोगकर्ता नाम देख सकते हैं, तो कोई भी रिवर्स लुकअप समान मान वापस करने वाला है।

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

आमतौर पर मैं रूट एक्सेस के लिए sudo के बजाय 'su' का उपयोग करता हूं।


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

8
तीसरा विकल्प सिर्फ एक खूनी बुरा विचार है । आप अनिवार्य रूप से यूआईडी और उपयोगकर्ता नाम के बीच 1: 1 संबंध तोड़ रहे हैं, और सचमुच यूनिक्स में सब कुछ उस संबंध को बनाए रखने की उम्मीद करता है। सिर्फ इसलिए कि ऐसा करने के लिए कोई स्पष्ट नियम नहीं है इसका मतलब यह नहीं है कि यह एक अच्छा विचार है।
शादुर

क्षमा करें, लेकिन तीसरा विकल्प एक भयानक विचार है। कई यूआईडी 0 वाले लोग लॉग इन कर रहे हैं, बस समस्याओं को गुणा करने के लिए कह रहे हैं। विकल्प संख्या 2 एकमात्र एकमात्र है।
डग

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

@ पैट्रिक क्या आपने इसे व्यवहार में देखा है? जितना मैंने परीक्षण किया, उसके बाद अनुप्रयोग rootउपयोगकर्ता को लेते हैं यदि rootउपयोगकर्ता /etc/passwdUID 0. के साथ पहले वाला है तो मैं jlliagre से सहमत हूं। एकमात्र नकारात्मक पहलू जो मुझे दिखाई देता है, वह यह है कि प्रत्येक उपयोगकर्ता एक rootउपयोगकर्ता है और कभी-कभी यह समझने में भ्रमित हो सकता है कि किसने क्या किया।
मार्टिन

2

मैं (1) का उपयोग करता हूं, लेकिन मैं टाइप करने के लिए हुआ

rm -rf / tmp *

यदि आप एक मुट्ठी भर से अधिक व्यवस्थापक हैं, तो मैं एक बुरा दिन देख सकता हूँ।

(2) शायद अधिक इंजीनियर है - और आप सुडो सु के माध्यम से पूर्ण जड़ बन सकते हैं। हालांकि अभी भी दुर्घटनाएं संभव हैं।

(३) मैं बजरे के खंभे से नहीं छूता। मैंने इसका उपयोग नॉन-नॉनबोन-श रूट अकाउंट (अगर मुझे सही से याद है) करने के लिए, सन पर किया था, लेकिन यह कभी भी मजबूत नहीं था - इसके अलावा मुझे संदेह है कि यह बहुत ही सराहनीय होगा।


2

निश्चित रूप से उत्तर 2।

  1. इसका मतलब है कि आप SSH की पहुँच की अनुमति दे रहे हैं root। यदि यह मशीन किसी भी तरह से सार्वजनिक सामना कर रही है, तो यह सिर्फ एक भयानक विचार है; जब मैं एसएसएच को पोर्ट 22 पर चलाता था, तो मेरे वीपीएस को रूट के रूप में प्रमाणित करने के लिए प्रति घंटा कई प्रयास मिलते थे। मेरे पास आईपी को लॉग इन करने और प्रतिबंध लगाने के लिए एक बुनियादी आईडीएस था जिसने कई असफल प्रयास किए, लेकिन वे आते रहे। शुक्र है, जैसे ही मैंने अपना खाता और sudo कॉन्फ़िगर किया, मैंने SSH को रूट उपयोगकर्ता के रूप में अक्षम कर दिया। इसके अतिरिक्त, आपके पास वस्तुतः कोई ऑडिट ट्रेल नहीं है।

  2. जरूरत पड़ने पर रूट एक्सेस प्रदान करता है। हां, आपके पास एक मानक उपयोगकर्ता के रूप में बमुश्किल कोई विशेषाधिकार है, लेकिन यह वही है जो आप चाहते हैं; यदि कोई खाता समझौता नहीं करता है, तो आप चाहते हैं कि वह अपनी क्षमताओं में सीमित हो। आप चाहते हैं कि किसी भी सुपर यूजर को पासवर्ड री-एंट्री की आवश्यकता हो। इसके अतिरिक्त, sudo पहुंच को उपयोगकर्ता समूहों के माध्यम से नियंत्रित किया जा सकता है, और यदि आप चाहें तो किसके पास अधिक नियंत्रण है, इसे विशेष कमांड तक सीमित कर सकते हैं। इसके अतिरिक्त, sudo के रूप में चलाए जाने वाले कमांड को लॉग किया जा सकता है, इसलिए यदि चीजें गलत होती हैं तो यह बहुत बेहतर ऑडिट ट्रेल प्रदान करता है। ओह, और जैसे ही आप लॉग इन करते हैं, "sudo su -" नहीं चलता। यह भयानक, भयानक अभ्यास है।

  3. आपके सिसादमिन का विचार बुरा है। और उसे बुरा लगना चाहिए। नहीं, * निक्स मशीनें शायद आपको ऐसा करने से नहीं रोकेंगी, लेकिन आपकी फ़ाइल प्रणाली और वस्तुतः हर एप्लिकेशन को प्रत्येक उपयोगकर्ता से एक अद्वितीय यूआईडी की उम्मीद है। यदि आप इस सड़क से नीचे जाना शुरू करते हैं, तो मैं गारंटी दे सकता हूं कि आप समस्याओं में भाग लेंगे। शायद तुरंत नहीं, लेकिन अंततः। उदाहरण के लिए, अच्छा दोस्ताना नाम प्रदर्शित करने के बावजूद, फाइलें और निर्देशिका अपने मालिकों को नामित करने के लिए यूआईडी नंबर का उपयोग करती हैं; यदि आप उस प्रोग्राम में भाग लेते हैं जिसमें लाइन के नीचे डुप्लिकेट यूआईडी की समस्या है, तो आप कुछ गंभीर मैनुअल फाइल सिस्टम क्लीनअप किए बिना बाद में अपनी पासवार्ड फाइल में यूआईडी नहीं बदल सकते।

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


1

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


1

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

आजकल, सूडो एकमात्र उपयुक्त समाधान है। कुछ और भी भूल जाओ।


0

यह तथ्य से अनुमेय दस्तावेज है। बीएसडी यूनियनों के पास लंबे समय तक अपना टॉर खाता रहा है, और बश्रोत उपयोगकर्ता उन प्रणालियों पर स्वीकार किए जाते हैं, जहां csh मानक है (स्वीकार किए गए कदाचार;)


0

शायद मैं अजीब हूँ, लेकिन विधि (3) है जो मेरे दिमाग में पहले से ही पॉपअप है। पेशेवरों: आपके पास लॉग में प्रत्येक उपयोगकर्ता का नाम होगा और पता होगा कि रूट के रूप में किसने क्या किया। विपक्ष: वे हर समय जड़ होंगे, इसलिए गलतियाँ भयावह हो सकती हैं।

मैं प्रश्न करना चाहूंगा कि रूट एक्सेस के लिए आपको सभी प्रवेशों की आवश्यकता क्यों है। आपके द्वारा प्रस्तावित सभी 3 विधियों में एक अलग नुकसान है: एक बार एक व्यवस्थापक sudo bash -lया एक या एक से चलाता है sudo su -, तो आप यह ट्रैक करने की अपनी क्षमता खो देते हैं कि कौन क्या करता है और उसके बाद, एक गलती भयावह हो सकती है। इसके अलावा, संभव दुर्व्यवहार के मामले में, यह भी एक बहुत बुरा अंत हो सकता है।

इसके बजाय आप एक और रास्ता तय करने पर विचार कर सकते हैं:

  • अपने व्यवस्थापक उपयोगकर्ताओं को नियमित उपयोगकर्ता बनाएं
  • तय करें कि किसको क्या काम करना है (अपाचे प्रबंधन / पोस्टफिक्स मैनेजमेंट आदि)
  • उपयोगकर्ताओं को संबंधित समूहों में जोड़ें (जैसे "मार्टिंक" को "पोस्टफिक्स" और "मेल", "एमाविस" में जोड़ें यदि आप इसका उपयोग करते हैं, आदि)
  • अनुमतियाँ ठीक करें (chmod -R g + w पोस्टफ़िक्स: पोस्टफ़िक्स / आदि / पोस्टफ़िक्स)
  • केवल रिश्तेदार सूद शक्तियों को दें: (visudo -> मार्टिन को /etc/init.d/postfix, / usr / bin / postsuper आदि का उपयोग करने दें)

इस तरह, मार्टिन सुरक्षित रूप से पोस्टफिक्स को संभालने में सक्षम होगा, और गलती या दुर्व्यवहार के मामले में, आप केवल अपने पोस्टफिक्स सिस्टम को ही खो देंगे, न कि पूरे सर्वर को।

समान तर्क किसी अन्य उप-प्रणाली पर लागू किया जा सकता है, जैसे कि अपाचे, mysql, आदि।

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


मुझे इस संदर्भ में SSH कनेक्शनों को संभालना बहुत ही बुनियादी होना चाहिए। जो भी विधि आप उपयोग करते हैं, SSH पर रूट लॉगिन की अनुमति न दें, व्यक्तिगत उपयोगकर्ताओं को अपनी स्वयं की साख के साथ जाने दें, और वहां से sudo / nosudo / etc को संभालें।
टुनके गोनकुएलु नोव
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.