क्या एक साझा उपयोगकर्ता के रूप में लॉगिंग एक बुरी आदत है?

Question

मैंने उन संगठनों में काम किया है जहां प्रति व्यक्ति एक नया उबंटू उपयोगकर्ता बनाने के बजाय जो एक मशीन में लॉग इन करना चाहता है, सिसड्मिन बस प्रत्येक उपयोगकर्ता की ssh कुंजी जोड़ते हैं .ssh/authorized_keys, और सभी sshको मशीन के रूप में ( जैसे ) ubuntu@hostया ec2-user@host। (संयोग से, मैंने इसे एक लैब सेटिंग में साझा मैक मिनिस पर भी देखा है।) क्या यह स्वीकार किया गया अभ्यास है, या एक विरोधी पैटर्न?

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

Comments

जबकि कई लोगों को पॉली-एमोरस संबंधों से परेशानी होती है, अन्य लोग उन्हें बस ठीक से संभालते हैं, इसलिए मुझे नहीं लगता कि यह साझा करने के लिए जरूरी "बुरी आदत" है ... ओह, कोई बात नहीं, आपका मतलब उपयोगकर्ता खाता है ।

— होपलेसनब बी

Awww, किसी ने clickbait शीर्षक को संपादित किया .. :(

— Burgi

Answer 1

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

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

Comments

यह दुर्भावना भी नहीं है, और यह अक्षमता भी नहीं है। जब मैं कुछ भी काम नहीं करता, तो मैं यह नहीं मान सकता कि मुझे इस खाते पर किया गया कुछ भी याद होगा।

— djechlin

सुरक्षित डेटा के सिद्धांत: अखंडता गोपनीयता उपलब्धता जवाबदेही। +1 शब्द जवाबदेही का उपयोग करने के लिए

— डेवलपर 24

Answer 2

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

विकल्प क्या होगा? कुछ चीजों को एक निश्चित उपयोगकर्ता के रूप में किया जाना चाहिए, रूट का उल्लेख नहीं करना चाहिए। Sudo? यह कुछ बहुत ही प्रतिबंधित कार्यों के लिए ठीक है, लेकिन मशीन को नष्ट करने के लिए नहीं।

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

प्रमाणीकरण, प्राधिकरण, और लेखा (AAA) क्लासिक अभिव्यक्ति है: आप अपने ssh कुंजी के साथ प्रमाणित हैं, आप कुछ भी करने के लिए अधिकृत हैं जो सामान्य उपयोगकर्ता कर सकता है क्योंकि आपकी कुंजी अधिकृत_की में है, और आपको लेखांकन की आवश्यकता है ताकि आप क्या करें तथ्य के बाद समीक्षा की जा सकती है।

Comments

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

— कानून

sudoमशीन के सामान्य प्रशासन के लिए बिल्कुल स्वीकार्य क्यों नहीं है?

— ब्लैकलाइट चमक

आप "एक अत्यंत सुरक्षित वातावरण" ऊ में जड़ के रूप में ssh?

— xaa

@BlacklightShining यदि आपको कुछ भी करने में सक्षम होना है (चाउन, चोमॉड मनमानी फाइलें, सर्वर स्थापित करें, फाइलसिस्टम माउंट करें, तो उपयोगकर्ता के रूप में sshing और sudo बैश करने से कुछ भी हासिल नहीं होगा। इसके बजाय, लॉगिंग रिले का उपयोग करने में ssh करें। और / या ssh कुंजी के t.he मालिक के साथ किसी दूरस्थ सर्वर पर सब कुछ लॉग इन करें।

— Law29

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

— कानून

Answer 3

यह स्पष्ट रूप से प्रणाली के उपयोग के मामले पर निर्भर करता है। यदि समय-समय पर परीक्षण की व्यवस्था हो तो यह मेरे लिए ठीक है। हमारे पास भी ऐसे सिस्टम हैं। यदि कंपनी के पास किसी भी प्रकार का पहचान प्रबंधन (LDAP, IPA) नहीं है, तो यादृच्छिक सिस्टम पर किसी भी रिमोट कंट्रोल के बिना नया उपयोगकर्ता बनाना काफी बोझ है।

लेकिन हर दिन के काम के लिए जब कोई गलती करता है तो पूरी कंपनी संचालित करने में असमर्थ होती है, यह एक अच्छा विचार नहीं है।

Comments

यदि आपके पास कोई निर्देशिका सेवा नहीं है या नहीं, तो हज़ारों खाते बनाना और प्रबंधित करना अव्यवहारिक है।

— जिम बी

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

— मार्टिज़न हेमेल्स

Answer 4

वे सभी उत्तर जवाबदेही की चिंता को संबोधित करते हैं जो अपने आप में एक महत्वपूर्ण और वास्तविक मुद्दा है, लेकिन एक साझा खाते का उपयोग करने से अन्य उपयोगकर्ताओं पर भी सूक्ष्म हमले नहीं होते हैं:

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

मूल रूप से, कंप्यूटर पर एक साझा खाते का उपयोग करना सार्वजनिक स्विमिंग पूल में पैर स्नान से पीने के समान है।

Answer 5

सामान्य तौर पर, एक खाते को साझा करना निम्नलिखित कारणों से एक बुरा विचार है:

1. इस उपयोगकर्ता के लिए की गई प्रत्येक सेटिंग हर किसी को लॉग इन करने का प्रभाव डालती है (Promt, aliases, ...)
   2. आप यह पता लगाने की संभावना खो देते हैं कि किसने क्या किया (जवाबदेही)
   3. खाते के कॉन्फ़िगरेशन में एक गलती (उदाहरण के लिए गलती से ssh kay को हटाना) उस उपयोगकर्ता खाते (उदाहरण में लॉक आउट) का उपयोग करके सभी को प्रभावित करता है।

और फिर यकीन है कि और भी डाउनसाइड हैं ... लेकिन मैं इसे और आगे नहीं बढ़ाना चाहता।

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

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

ऑडिटिंग उपकरण अभी भी आपको ट्रैक करने की अनुमति देगा कि किसने निष्पादित किया है लेकिन अभी भी उसी खाते को साझा कर रहा है।