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


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

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

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

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

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

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

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

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

  • लाभ: एसएसएच एजेंट अग्रेषण कार्य करता है, लेखा परीक्षा कार्य कर सकती है (अवांछित), नहीं sudo परेशानी
  • नुकसान: बहुत गंदा लगता है - इसे कहीं भी स्वीकृत तरीके से दस्तावेज नहीं मिला

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


38
2018-05-21 09:58


मूल


आपके बारे में "इसे किसी भी तरह से स्वीकृत तरीके से दस्तावेज नहीं मिला" कथन: एक नज़र डालें -o में झंडा useradd मैनुअल पेज यह ध्वज एक ही यूआईडी साझा करने वाले एकाधिक उपयोगकर्ताओं को अनुमति देने के लिए है। - jlliagre
क्या आप दूसरे विकल्प में "एसएसएच एजेंट अग्रेषण ब्रेक" से क्या मतलब समझ सकते हैं? हम इसे अपने काम पर इस्तेमाल करते हैं और एसएसएच एजेंट अग्रेषण ठीक काम करता है। - Patrick
आपको सूडो के बजाय अपने गैर-रूट खाते से बाहर निकलना चाहिए। - Random832
सुडो विधि का एक अन्य परिणाम: अब आप रूट के रूप में एससीपी / एफ़टीपी नहीं कर सकते हैं। किसी फ़ाइल स्थानांतरण को पहले व्यक्ति की होम निर्देशिका में स्थानांतरित करने की आवश्यकता होगी और फिर टर्मिनल में कॉपी की जाएगी। परिप्रेक्ष्य के आधार पर यह एक लाभ और नुकसान है। - user606723
कठपुतली / महाराज / उत्तर-प्रकार के सिस्टम क्यों नहीं माना जा रहा है? - Alex Holst


जवाब:


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

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

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


63
2018-05-21 10:21



एसएसएच द्वारा पूरी तरह रूट पहुंच को अक्षम करने के बजाय, मैं अनुशंसा करता हूं कि एसएसएच द्वारा रूट एक्सेस की आवश्यकता है, एक बहुत मजबूत कीफ्रेज़ के साथ एक कुंजी बनाना और इसे आपातकालीन उपयोग के लिए बंद कर देना। यदि आपके पास स्थायी कंसोल पहुंच है तो यह कम उपयोगी है, लेकिन यदि आप नहीं करते हैं, तो यह बहुत आसान हो सकता है। - EightBitTony
मैं सुरक्षा प्रयोजनों के लिए एसएसएच पर रूट लॉगिन अक्षम करने की अनुशंसा करता हूं। यदि आपको वास्तव में रूट के रूप में लॉग इन करने की आवश्यकता है, तो गैर-रूट उपयोगकर्ता और su के रूप में लॉग इन करें। - taz
+1 .. मैं कहने से आगे जाऊंगा "दूसरा विकल्प सबसे अच्छा है"। मैं यह एकमात्र उचित विकल्प होगा। विकल्प एक और तीन बाहरी हमलों और गलतियों दोनों से सिस्टम की सुरक्षा को काफी कम करता है। इसके अलावा, # 2 यह है कि सिस्टम कैसा था डिज़ाइन किया गया मुख्य रूप से इस्तेमाल किया जाना है। - Ben Lee
कृपया, विस्तृत करें sudo -s। क्या मैं इसे समझने में सही हूं sudo -i उपयोग करने में कोई फर्क नहीं पड़ता है su - या सादे रूट लॉगिन की तुलना में अतिरिक्त लॉग प्रविष्टि के अलावा मूल रूप से रूट के रूप में लॉग इन करना? यदि यह सच है, तो सादा रूट लॉगिन से यह कैसे और क्यों बेहतर है? - PF4Public


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

मुझे लगता है कि पहले विकल्प के बारे में मेरा पहला अवलोकन "हर किसी की एसएसएच पब्लिक की कुंजी को रूट /। एसएसएच / अधिकृत_कीएस 2 में रखा गया है", यह तब तक है जब तक आप पूरी तरह से किसी भी अन्य सिस्टम पर काम नहीं कर रहे हैं;

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

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

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

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

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

इसलिए मैं उन कुछ चालों को पार कर सकता हूं जिनका उपयोग मैं काम करने के लिए करता हूं-आसपास की परेशानियों के आसपास sudo आप उल्लेख करते हैं। पहली समस्या यह है कि यदि रूट लॉगिन का उपयोग कर अवरुद्ध किया गया है PermitRootLogin=no या आपके पास एसएसएच कुंजी का उपयोग कर रूट नहीं है, तो यह एससीपी फाइलों को पिटा के कुछ बनाता है।

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

उबाऊ समाधान: फ़ाइलों को होम निर्देशिका, चोटी, और एसपीपी नीचे कॉपी करें।

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

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

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

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

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

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

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

रिमोट होस्ट पर लॉग इन करें, लेकिन निर्दिष्ट करें कि रिमोट पोर्ट 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_AUTH_SOCK रीसेट कर रहे हैं, इसलिए एसएसएच एजेंट अग्रेषण "टूटा हुआ" है 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# 

9
2018-05-21 19:24



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


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

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

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


2
2018-05-21 10:16



एक ही यूआईडी के साथ कई उपयोगकर्ताओं को जोड़ना समस्याएं जोड़ता है। जब एप्लिकेशन यूआईडी नंबर के लिए उपयोगकर्ता नाम देखने के लिए जाते हैं, तो वे गलत उपयोगकर्ता नाम देख सकते हैं। रूट के तहत चलने वाले अनुप्रयोगों को लगता है कि वे गलत उपयोगकर्ता के रूप में चल रहे हैं, और बहुत सी अजीब त्रुटियां पॉप-अप शुरू हो जाएंगी (मैंने इसे एक बार कोशिश की)। - Patrick
तीसरा विकल्प सिर्फ एक है खूनी बुरा विचार। आप अनिवार्य रूप से यूआईडी और उपयोगकर्ता नामों के बीच 1: 1 संबंध तोड़ रहे हैं, और शाब्दिक रूप से सब कुछ यूनिक्स में उम्मीद है कि पकड़ के संबंध में। सिर्फ इसलिए कि कोई स्पष्ट नियम नहीं है, इसका मतलब यह नहीं है कि यह एक अच्छा विचार है। - Shadur
क्षमा करें, लेकिन तीसरा विकल्प एक भयानक विचार है। कई यूआईडी 0 लोग लॉग इन करने के कारण सिर्फ गुणा होने के लिए पूछ रहे हैं। विकल्प संख्या 2 एकमात्र सीन है। - Doug
तीसरा विकल्प कई डाउनवॉट्स के लायक नहीं है। यूनिक्स में कोई आदेश नहीं है, मुझे पता है कि इस चाल से उलझन में है, लोग हो सकते हैं लेकिन कमांडों पर ध्यान नहीं दिया जाना चाहिए। यह सिर्फ एक अलग लॉगिन नाम है, लेकिन जैसे ही आप लॉग इन हैं, पासवर्ड डेटाबेस में यूआईडी से मेल खाने वाला पहला नाम उपयोग किया जाता है, इसलिए बस सुनिश्चित करें कि असली उपयोगकर्ता नाम (यहां रूट) पहले दिखाई देता है। - jlliagre
@ पैट्रिक क्या आपने इसे अभ्यास में देखा है? जितना मैंने परीक्षण किया, तब आवेदन उठाएं root उपयोगकर्ता अगर root उपयोगकर्ता में पहला है /etc/passwd यूआईडी 0 के साथ। मैं jlliagre से सहमत हैं। मैं देखता हूं कि एकमात्र नकारात्मक पक्ष यह है कि प्रत्येक उपयोगकर्ता एक है root उपयोगकर्ता और कभी-कभी यह समझने में भ्रमित हो सकता है कि किसने किया। - Martin


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

आरएम-आरएफ / टीएमपी *

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

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

(3) मैं एक बार्ज ध्रुव के साथ छूना नहीं होगा। मैंने इसे गैर-बेरबोन-आर रूट खाता (यदि मुझे सही याद है) रखने के लिए सनस पर इसका इस्तेमाल किया, लेकिन यह कभी मजबूत नहीं था - साथ ही मुझे संदेह है कि यह बहुत ही ऑडिटेबल होगा।


2
2018-05-21 16:51





निश्चित रूप से जवाब 2।

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

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

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

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


2
2018-05-21 17:29





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


1
2018-05-21 19:25





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

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


1
2018-05-22 09:15