एकाधिक गीथब परियोजनाओं के लिए एक ही तैनाती कुंजी का उपयोग

Question

गिथब एक से अधिक परियोजनाओं के लिए एक ही एसएसएच तैनाती कुंजी का उपयोग करने की अनुमति नहीं देता है, जो कुछ मामलों में बहुत उपयोगी होगा (उदाहरण के लिए सीआई सर्वर निजी उप-मॉड्यूल के साथ परियोजना से निपट रहा है)। मैंने विभिन्न धागे देखे हैं जो कहते हैं कि यह सीमा 'सुरक्षा कारणों' के लिए है, लेकिन मुझे अभी तक एक जोखिमपूर्ण स्पष्टीकरण नहीं दिख रहा है कि वास्तव में कौन सा जोखिम उठाएगा।

ध्यान दें कि गीथब खाता स्तर कुंजी का पुन: उपयोग करने की अनुमति नहीं देता है (दो उपयोगकर्ताओं को कुंजी साझा नहीं करना चाहिए)। यह केवल पर प्रतिबंध पर प्रतिबंध है जिसे मैं पूछताछ कर रहा हूं।

और स्पष्ट होना, मैं कर रहा हूँ नहीं समाधानों की तलाश में (एक डमी उपयोगकर्ता बनाने, कई चाबियाँ, ... का उपयोग करें), लेकिन केवल तैनात कुंजी पर इस सीमा के लिए एक प्रशंसनीय विवरण के लिए।

संबंधित धागे:

• एक दिखा एक workaround
• एक discussing the issue नहीं बल्कि वास्तव में कहीं भी

Answer 1

एकमात्र कारण, वैकल्पिक हल आप संदर्भ द्वारा सचित्र जा रहा (बनाने के लिए एक एकल "का निर्माण" उपयोगकर्ता, या एक ही id_rsa.REPONAME.pub प्रति रेपो साझा करना) है:

अन्य उपयोगकर्ता के लिए सार्वजनिक/निजी कुंजी साझा करने से बच

हालांकि कि अपनी स्थिति में ऐसा नहीं होगा (एकाधिक परियोजना का निर्माण), एक ही ssh कुंजी का पुन: उपयोग करने के लिए दो अलग उपयोगकर्ताओं के लिए संभावना खोलेगा की इजाजत दी उसी एसएसएच कुंजी को साझा करें, जो प्रमाणीकरण उद्देश्य को हरा देगा।

प्रमाणीकरण का अर्थ है:
"एक निश्चित ssh कुंजी का उपयोग कर संकेत करना चाहिए कि आप करने वाले हैं पता है जो यह उपयोग कर रहा है"।

---

GitHub पेज "Managing deploy keys" विभिन्न खातों ssh का उपयोग कर विवरण:

• SSH एजेंट अग्रेषण: एजेंट अग्रेषण पहले से ही अपने स्थानीय विकास मशीन जब पर स्थापित SSH कुंजियों का उपयोग करता है आप अपने सर्वर में एसएसएच और गिट कमांड चलाते हैं।
  आप चुनिंदा सर्वर को अपने स्थानीय एसएसएच-एजेंट तक पहुंचने के लिए चुन सकते हैं जैसे कि यह सर्वर पर चल रहा था।
  इसलिए सर्वर पर अपनी निजी कुंजी को दोहराने की कोई आवश्यकता नहीं है।

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

• कुंजी (एक प्रति गिटहब रेपो) एसएसएच कुंजी जो सर्वर पर संग्रहीत है और गिटहब पर एक एकल रेपो तक पहुंच प्रदान करता है।
  यह कुंजी सीधे उपयोगकर्ता खाते के बजाय रेपो से जुड़ी हुई है।
  अपनी खाता सेटिंग्स पर जाने के बजाय, लक्षित रेपो के व्यवस्थापक पृष्ठ पर जाएं।
  "Deploy Keys" पर जाएं और "Add deploy key" पर क्लिक करें। सार्वजनिक कुंजी को पेस्ट करें और सबमिट करें।

इस बार, एसएसएच कुंजी किसी उपयोगकर्ता से जुड़ी नहीं है (जिसके लिए आप कई रेपो तक पहुंच प्रदान कर सकते हैं), लेकिन एक रेपो के लिए।
के लिए एसएसएच पहुंच प्रदान करना कई रेपो "मशीन उपयोगकर्ता" के बराबर होगा।

प्रमाणीकरण के कार्यकाल में:

• कई रेपोस के लिए एक ही कुंजी का उपयोग ठीक है जब यह
• का उपयोग कर (कुंजी उसकी/उसके खाते से संबद्ध ने कहा है कि जो) एक उपयोगकर्ता द्वारा किया जाता है है कई रेपो के लिए एक ही कुंजी ठीक नहीं है जब कुंजी रेपो द्वारा जुड़ी होती है, क्योंकि आप पर नहीं जानते हैं जो पर पहुंचा है।
  यह "मशीन उपयोगकर्ता" से अलग है जहां कई उपयोगकर्ता के लिए एक "उपयोगकर्ता" को सहयोगी के रूप में घोषित किया जाता है।
  यहां (कुंजी तैनात करें), कोई "सहयोगी" नहीं है, रेपो को दी गई एक सीधी एसएसएच पहुंच है।

Answer 2

इसने मुझे परिदृश्य को तर्कसंगत बनाने और इस परिदृश्य के साथ आने के लिए बहुत सारी सोच ली।

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

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

यह बहुत ही अनूठी चाबियाँ असाइन करने और प्रबंधित करने के लिए निश्चित रूप से निराशाजनक है लेकिन सुरक्षा प्रभाव इस बात से स्पष्ट हैं कि गिटहब ने अपनी नीति कैसे स्थापित की है: जब आप किसी कुंजी को निरस्त करते हैं तो आपको उस कुंजी द्वारा दी गई सभी पहुंच को निरस्त करने की गारंटी दी जाती है क्योंकि यह है केवल एक ही स्थान पर प्रयोग किया जाता है।