सवाल एक टीम में एसएसएच कुंजी के प्रबंधन के लिए सर्वोत्तम प्रथाएं क्या हैं?


मैं निम्नलिखित विशेषताओं के साथ डेवलपर्स और प्रशासकों की छोटी टीमों (<10) के साथ काम करता हूं:

  • टीम के अधिकांश सदस्यों में> 1 पर्सनल कंप्यूटर है, जिनमें से अधिकांश पोर्टेबल हैं
  • टीम के सदस्यों के पास आमतौर पर सूडो के साथ 10-50 सर्वर तक पहुंच होती है

मुझे लगता है कि यह ज्यादातर स्टार्टअप और छोटे से मध्य आकार के कॉर्पोरेट आईटी समूहों के लिए काफी विशिष्ट है।

इस तरह की टीम में एसएसएच कुंजी के प्रबंधन के लिए सर्वोत्तम प्रथाएं क्या हैं?

क्या आपको पूरी टीम के लिए एक ही कुंजी साझा करनी चाहिए?

क्या प्रत्येक व्यक्ति के पास साझा खाते (प्रत्येक सर्वर पर "उबंटू") पर अपनी कुंजी होनी चाहिए?

अलग खाते?

क्या प्रत्येक टीम के सदस्य अपने प्रत्येक लैपटॉप या डेस्कटॉप कंप्यूटर के लिए एक अलग कुंजी रखना चाहिए?


40
2018-01-23 16:07


मूल




जवाब:


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

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

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

Host prod-*.example.com
     User jsmith
     ForwardAgent yes
     ProxyCommand ssh -q bastion.example.com "nc %h %p"


31
2018-01-23 17:24



यह वास्तव में एक अच्छा जवाब है! अनुवर्ती प्रश्न: आप caengine का उपयोग .authorized_keys वितरित करने के लिए करते हैं। क्या आपने सीधे अपने एलडीएपी सर्वर में एसएसएच पब्लिक कुंजियों को स्टोर करने के किसी भी तरीके से देखा है? उन्हें ज्यादातर पैचिंग एसएसडीडी की आवश्यकता होती है, जो नाजुक लगता है। - Evan Prodromou
मैंने शेफ के साथ कुछ ऐसा किया है। - gWaldo
@EvanProdromou मैंने एलडीएपी में एसएसएच पब्लिक चाबियाँ स्थापित की हैं, लेकिन यह मूल्यवान की तुलना में कहीं अधिक परेशानी थी, क्योंकि मुझे एसएसएच पैकेज को अद्यतित करना था, और यह कुछ एसएसएच भेद्यता के समय था - Daniel Lawson
सुडो नियम और एसएसएच कुंजी एलडीएपी में भी रखी जा सकती हैं, एसएसएसडी का इस्तेमाल इसे स्थापित करने के लिए किया जा सकता है। लिंक: sudo.ws/sudoers.ldap.man.html तथा access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/... - fuero
मुझे पसंद हैं तुम्हारा ProxyCommand ssh -q थोड़ा सा! कभी नहीं देखा मुझे एक बुर्ज सर्वर स्थापित करने में संकोच नहीं है, लेकिन यदि यह अंतिम उपयोगकर्ताओं के लिए पारदर्शी हो सकता है तो मैं इसके लिए सब कुछ हो सकता हूं। धन्यवाद मार्टिन! - the0ther


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

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

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


6
2018-01-23 16:55





मेरे पास ऐसी स्थिति है जहां मुझे 40 डेवलपर्स की टीम के लिए ~ 120 रिमोट ग्राहक सर्वरों के लिए एसएसएच कुंजी पहुंच प्रदान करने की आवश्यकता है।

मैंने डेवलपर्स को एक "जंप होस्ट" से जुड़ने के लिए मजबूर कर नियंत्रित किया। उस मेजबान से, मैंने निजी / सार्वजनिक कुंजी उत्पन्न की और उन्हें ग्राहक सर्वर पर धक्का दिया। यदि डेवलपर्स को लैपटॉप से ​​एक्सेस की आवश्यकता होती है, तो वे अपने स्थानीय सिस्टम पर एक ही कीपर का उपयोग कर सकते हैं।


5
2018-01-23 17:22





मैं व्यक्तिगत रूप से प्रति उपयोगकर्ता के साथ जाऊंगा, तो आपको तत्काल उत्तरदायित्व और सेट प्रतिबंधों को और आसानी से सेट किया जाएगा - मुझे नहीं पता कि अन्य लोग क्या सोचते हैं?


2
2018-01-23 16:28





एक दृष्टिकोण जिसे मैंने सुना है, लेकिन खुद का उपयोग नहीं किया है, प्रत्येक उपयोगकर्ता के पास एक पैकेज (उदाहरण के लिए, .deb, .rpm) है जिसमें उनके एसएसएच सार्वजनिक कुंजी कॉन्फ़िगरेशन, साथ ही साथ किसी भी डॉटफाइल को अनुकूलित करना पसंद है (.bashrc , .profile, .vimrc आदि)। यह एक कंपनी भंडार में हस्ताक्षरित और संग्रहीत है। यह पैकेज उपयोगकर्ता खाता बनाने के लिए भी ज़िम्मेदार हो सकता है, या यह खाता बनाने (सीएफएनजीन / कठपुतली आदि) या एलडीएपी जैसे केंद्रीय लेख प्रणाली को कुछ और पूरक कर सकता है।

इन पैकेजों को तब होस्ट्स पर स्थापित किया जाता है जो आप पसंद करते हैं (सीएफएनजीन / कठपुतली आदि, क्रॉन जॉब)। एक दृष्टिकोण एक मेटापेकेज होना है जिस पर प्रति उपयोगकर्ता पैकेज पर निर्भरता है।

यदि आप सार्वजनिक कुंजी को हटाना चाहते हैं, लेकिन उपयोगकर्ता नहीं, तो प्रति उपयोगकर्ता पैकेज अपडेट किया गया है। यदि आप किसी उपयोगकर्ता को हटाना चाहते हैं, तो आप पैकेज को हटा दें।

यदि आपके पास विषम सिस्टम हैं और दोनों .rpm और .deb फ़ाइलों को बनाए रखना है, तो मैं इसे थोड़ा परेशान कर सकता हूं, हालांकि विदेशी जैसे टूल कुछ आसान बना सकते हैं।

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


2
2018-01-23 20:35





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

यदि आपके पास उपयोगकर्ताओं के बीच साझा कुंजी है --- भले ही आप एक छोटी टीम हों --- एक कुंजी को रद्द करना हर किसी के लिए असुविधा है।

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


1
2018-01-25 02:35





कुछ साल पहले ईवी लैब्स ने विकास टीमों के लिए ऐसा कुछ संभालने के लिए कीमास्टर नामक एक उपकरण लिखा था (क्लाइंट गेटकीपर के साथ भागीदारी की थी)।

इस परियोजना को पिछले दो सालों में ज्यादा प्यार नहीं हुआ है, लेकिन ऐसा कुछ ऐसा है जो आप टिंकर कर सकते हैं, और शायद जीवन में वापस ला सकते हैं?

रेपो गिटूब में उपलब्ध है: https://github.com/envylabs/keymaster


1
2018-01-30 04:47





एनएफएस पर एनआईएस सर्वर / होम शेयर के साथ एक अपहरण स्थापित किया जा सकता है। यह सर्वर में सुडो के साथ मिलकर और केवल उन उपयोगकर्ताओं को अनुमति देता है जिन्हें आप प्रत्येक सर्वर को एसएसएच कॉन्फ़िगरेशन के माध्यम से चाहते हैं।

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

सादर,

राफेल


-4
2018-01-23 17:06



1) एनआईएस सक्षम करना एक सुरक्षा छेद है। 2) एक पासवर्ड और खाता होने के कारण पता लगाने और जवाबदेही के विपरीत है। - Deer Hunter