सवाल एसएसएच कुंजी के प्रबंधन के लिए सबसे अच्छी प्रणाली? [बन्द है]


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

विकल्प 1: एक वैश्विक सार्वजनिक / निजी कीपैयर।

मैं एक सार्वजनिक / निजी कीपैयर उत्पन्न करता हूं, और प्रत्येक ग्राहक मशीन पर निजी कुंजी डालता हूं, और प्रत्येक सर्वर मशीन पर सार्वजनिक कुंजी डालता हूं।

विकल्प 2: प्रति मशीन मशीन पर एक कीपैयर।

मैं प्रत्येक सर्वर मशीन पर एक कीपैयर उत्पन्न करूंगा, और अपनी क्लाइंट मशीनों पर प्रत्येक निजी कुंजी डालूंगा।

विकल्प 3: प्रति ग्राहक मशीन के लिए एक कीपैयर।

प्रत्येक क्लाइंट मशीन की एक अनन्य निजी कुंजी होगी, और प्रत्येक सर्वर मशीन में प्रत्येक क्लाइंट मशीन के लिए सार्वजनिक कुंजी होगी जो मैं कनेक्ट करना चाहता हूं।

विकल्प 4: क्लाइंट / सर्वर जोड़ी प्रति एक कीपैयर

पूरी तरह से overboard?

इनमें से कौन सा सबसे अच्छा है? क्या अन्य विकल्प हैं? सही कॉन्फ़िगरेशन का मूल्यांकन करने के लिए आप किस मानदंड का उपयोग करते हैं?


40
2018-05-27 22:32


मूल




जवाब:


मैं उपयोग करता हूं विकल्प 3: प्रति ग्राहक मशीन के लिए एक कीपैयर और यह मेरे लिए सबसे ज्यादा समझ में आता है। यहां कुछ कारण दिए गए हैं:

  • यदि किसी क्लाइंट से समझौता किया गया है तो उस कुंजी (और केवल उस कुंजी) को सर्वर से हटा दिया जाना चाहिए।
  • यह तय करने के लिए पर्याप्त लचीला है कि मैं कहां से पहुंच सकता हूं, सभी ग्राहकों के सभी सर्वरों को कंबल पहुंच प्रदान किए बिना।
  • बहुत ही सुविधाजनक। एसएसएच-एड के लिए केवल 1 कुंजी है, कोई भ्रम नहीं है।
  • स्थापित करने और प्रशासन करने में आसान है विकल्प 4

विकल्प 4 अच्छा है, लेकिन यह बहुत अधिक काम है। विकल्प 3 आपको बहुत कम परेशानी के साथ 98% मिल जाता है।


32
2018-05-27 22:44



मैं विकल्प 4 के बिंदु को देखने में असफल रहा। यह किसी भी उद्देश्य का कार्य नहीं करता है। - niXar


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

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

तब मेरे पास निम्न कॉन्फ़िगरेशन है ~/.ssh/config फ़ाइल:

Host *
    Protocol 2
    IdentityFile %d/.ssh/keys.d/id_rsa.%l
    IdentityFile %d/.ssh/keys.d/id_dsa.%l
    IdentityFile %d/.ssh/keys.d/%u@%l

% d OpenSSH द्वारा और उपयोगकर्ता में उपयोगकर्ता की होम निर्देशिका के रूप में अनुवादित किया गया है ~ / .Ssh निर्देशिका मैंने बनाई है keys.d एन्क्रिप्टेड यूएसबी ड्राइव पर निर्देशिका पथ पर एक सिम्लिंक के रूप में जब यह ठीक से घुड़सवार होता है।

% एल अभिव्यक्ति का अनुवाद स्थानीय क्लाइंट मशीन होस्टनाम और किया जाता है % u स्थानीय ग्राहक के उपयोगकर्ता नाम में अनुवाद किया जाएगा।

यह कॉन्फ़िगरेशन क्या करता है एसएसएच को 3 अलग-अलग अभिव्यक्तियों का उपयोग करके कुंजी की तलाश करने की अनुमति देता है। उदाहरण के लिए यदि मेरा स्थानीय ग्राहक का उपयोगकर्ता नाम था jdoeऔर मेरा स्थानीय ग्राहक मशीन नाम था examplehost यह निम्न क्रम में तब तक दिखेगा जब तक कि यह एक कुंजी नहीं मिली जो दोनों मौजूद थे और रिमोट सर्वर द्वारा स्वीकार किए गए थे।

/home/jdoe/.ssh/keys.d/id_rsa.examplehost
/home/jdoe/.ssh/keys.d/id_dsa.examplehost
/home/jdoe/.ssh/keys.d/jdoe@examplehost

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

अपडेट करें: अब मैं वास्तव में अपने ओपनपीजीपी वी 2 स्मार्टकार्ड से प्रमाणीकरण कुंजी को पढ़ने और उपयोग करने के लिए एसएसएच-एजेंट संगतता के साथ जीएनयूपीजी जीजीपी-एजेंट का उपयोग करता हूं।


26
2018-06-11 02:14



वाह, महान समाधान, धन्यवाद! मैं सार्वभौमिक विन्यास ~ / .ssh / config में प्यार करता हूँ - slacy
यह काम, व्यक्तिगत और परामर्श क्लाइंट नेटवर्क सर्वर के लिए चीजों को अलग रखने के लिए खुद को काफी सुविधाजनक साबित हुआ है ... मैं उनके बीच प्रमाणीकरण मिश्रण नहीं करना चाहता हूं बल्कि यह भी मेरे लिए आसान होना चाहता हूं। - Jeremy Bouse
गजब का! मुझे यह सचमुच पसंद है। - balu
मुझे लगता है कि आप विभिन्न क्लाइंट मशीनों के लिए विभिन्न यूएसबी कुंजी का उपयोग कर रहे हैं। अन्यथा अलग-अलग कुंजियों में बिंदु क्या है यदि उनमें से सभी एक ही स्थान पर संग्रहीत हैं? उल्लंघन के मामले में आपको उन सभी को रद्द करने की आवश्यकता होगी। जब तक (और शायद) मुझे कुछ याद आ रहा है, यह सिर्फ जटिल चीजों को लगता है। - Halil Özgür
@ HalilÖzgür, हाँ मैं परामर्श करता हूं और हमेशा एक ही कुंजी का उपयोग नहीं करना चाहता हूं। चूंकि यूएसबी कुंजी एन्क्रिप्ट की जाती है और किसी भी कंप्यूटर से कनेक्ट नहीं होती है जब तक कि मुझे कनेक्शन बनाने की आवश्यकता न हो, सर्वर का उल्लंघन करने की कोई चिंता नहीं है और ड्राइव फाइल सिस्टम को डिक्रिप्ट करने के लिए पासफ्रेज पर्याप्त रूप से काफी आसान बनाने के लिए पर्याप्त है। - Jeremy Bouse


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


6
2018-05-27 23:07



हाँ, एक उचित "विकल्प 2" का नाम बदल दिया गया है, मुझे "निजी कुंजी की प्रतिलिपि न बनाएं" का नियम पसंद है। यह एक अच्छा नियम है। - slacy


विकल्प 3 और कुंजी प्रबंधन को संभालने के लिए कठपुतली की तरह कुछ उपयोग करें।


1
2018-05-27 23:41



क्या इस reductivelabs.com/trac/puppet/wiki/PuppetIntroduction कठपुतली का लिंक? - Andy
हाँ बस यही। साइट पर कुछ उदाहरणों को देखना सुनिश्चित करें। यह देखने में मदद करता है कि दूसरों ने पहले ही क्या किया है - पहिया को फिर से शुरू करने की कोई आवश्यकता नहीं है। - diq


विकल्प 3।

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


1
2018-05-31 06:10