सर्वर व्यवस्थापक ने मुझे उपयोग करने के लिए एक निजी कुंजी भेजी। क्यों?

Question

मैं किसी कंपनी के मंचन और लाइव सर्वर को हमारे परिनियोजन लूप से जोड़ने के लिए एक सर्वर तक पहुंचने वाला हूं। उनकी ओर से एक व्यवस्थापक ने दो उदाहरण स्थापित किए और फिर सर्वर में हमारे लिए SSH के रूप में एक उपयोगकर्ता बनाया। यह मुझे बहुत आदत है।

मेरे दिमाग में अब क्या होगा मैं उन्हें अपनी सार्वजनिक कुंजी भेजूंगा जो उनके अधिकृत कुंजी फ़ोल्डर के अंदर रखी जा सकती है। हालाँकि इसके बजाय उन्होंने मुझे एक फ़ाइल नाम भेजा है id_rsaजिसमें फ़ाइल -----BEGIN RSA PRIVATE KEY-----ईमेल के अंदर है । क्या यह सामान्य है?

मैंने चारों ओर देखा और खरोंच से अपनी खुद की चाबियाँ बनाने और स्थापित करने पर कई टन संसाधन पा सकते हैं, लेकिन सर्वर की निजी कुंजी से शुरू करने के बारे में कुछ भी नहीं । क्या मुझे अपने लिए कुछ कुंजी उत्पन्न करने के लिए इसका उपयोग करना चाहिए या?

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

Comments

मैं इसे सामान्य या समझदार नहीं कहूंगा, लेकिन चूंकि आपके पास निजी कुंजी है (यह मानते हुए कि वे पहले से ही इसे अधिकृत के रूप में जोड़ चुके हैं) आप इसे किसी अन्य निजी कुंजी का उपयोग करने के रूप में उपयोग कर सकते हैं। आपको संबंधित सार्वजनिक कुंजी की आवश्यकता नहीं है, लेकिन यदि आप चाहते हैं, तो आप इसे हमेशा उत्पन्न कर सकते हैं: askubuntu.com/a/53555/158442

— muru

हो रही -----BEGIN RSA PRIVATE KEY-----ई-मेल से अधिक नाम के एक उपयोगकर्ता को देखने के बाद अगले डरावना बात है '); DROP DATABASE;--अपने उपयोगकर्ता नाम तालिका में।

— दिमित्री ग्रिगोरीव

@DmitryGrigoryev '); DROP DATABASE;--अपने डेटाबेस तालिका में एक उपयोगकर्ता नाम के रूप में देखने के बारे में कुछ भी डरावना नहीं है - यह दिखाता है कि आप उपयोगकर्ता इनपुट को सही ढंग से बच रहे हैं

— HorusKol

आप निश्चित रूप से 'इसका उपयोग नहीं कर सकते क्योंकि आप किसी अन्य निजी कुंजी का उपयोग करेंगे'। यह एक निजी नहीं है। एर्गो संभवतः उस फ़ंक्शन को पूरा नहीं कर सकता जिसके लिए इसे बनाया गया था। इसे फेंक दिया जाना चाहिए और UNIX व्यवस्थापक को गंभीर रूप से पीछा करना चाहिए। @ मुरु

— user207421

जिस किसी के पास भी यह निजी कुंजी है उसके पास नए सर्वर तक पहुंच है। संभवत: व्यवस्थापक को कुंजी की आवश्यकता के बिना किसी भी तरह पहुंच है, एस / वह सर्वर स्थापित करने में सक्षम था, इसलिए उसके द्वारा अनधिकृत पहुंच का कोई अतिरिक्त खतरा नहीं है। हालांकि, चूंकि यह आपकी कुंजी है, वह अब आपको दृढ़ता से प्रतिरूपण कर सकता है। यह भी मौका है कि आपके अलावा कोई व्यक्ति ईमेल पढ़ता है, और फिर वे आपको भी प्रतिरूपित कर सकते हैं।

— इम्बिसिस

Answer 1

मेरे दिमाग में अब क्या होगा मैं उन्हें अपनी सार्वजनिक कुंजी भेजूंगा जो उनके अधिकृत कुंजी फ़ोल्डर के अंदर रखी जा सकती है।

"आपके दिमाग में" क्या है जो अब होना चाहिए वह सही है।

ईमेल संचार का एक सुरक्षित चैनल नहीं है, इसलिए उचित सुरक्षा के दृष्टिकोण से, आपको (और उन्हें) उस निजी कुंजी पर विचार करना चाहिए।

आपके तकनीकी कौशल और आप कैसे राजनयिक होना चाहते हैं, के आधार पर, आप कई अलग-अलग काम कर सकते हैं। मैं निम्नलिखित में से एक की सिफारिश करूंगा:

1. अपनी खुद की कुंजी जोड़ी बनाएं और सार्वजनिक कुंजी को आपके द्वारा भेजे गए ईमेल में संलग्न करें, यह कहते हुए:

   धन्यवाद! चूंकि ईमेल निजी कुंजी के लिए एक सुरक्षित वितरण विधि नहीं है, क्या आप कृपया मेरी सार्वजनिक कुंजी को इसके स्थान पर रख सकते हैं? यह संलग्न है।

2. उन्हें धन्यवाद दें और उनसे पूछें कि क्या वे आपको अपनी खुद की कीपर स्थापित करने पर आपत्ति करते हैं, क्योंकि जो निजी कुंजी उन्होंने भेजी है, उसे ईमेल पर भेजे जाने के बाद समझौता माना जाना चाहिए।

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

नीचे पंक्ति: आप एक बेवकूफ की तरह नहीं दिखेंगे। लेकिन, दूसरे एडमिन को बहुत आसानी से बेवकूफ की तरह देखा जा सकता है। अच्छी कूटनीति इससे बच सकती थी।

---

मोंटीहार्डर की टिप्पणियों के जवाब में संपादित करें:

कार्रवाई के मेरे सुझाए गए पाठ्यक्रमों में से किसी में "दूसरे व्यवस्थापक को बताए बिना कि उसने क्या गलत किया है," चीजों को ठीक करना शामिल है; मैंने बस के नीचे उसे फेंकने के बिना इतनी सूक्ष्मता से किया।

हालाँकि, मुझे लगता है कि मैं भी (विनम्रता) का पालन करेंगे अगर सूक्ष्म सुराग नहीं उठाया गया था:

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

क्या आप समझते हैं कि मैं निजी कुंजी के सुरक्षित संचालन के बारे में यह बात क्यों कह रहा हूं?

श्रेष्ठ,

टोबी

Comments

+1 उत्तम उत्तर। और मैं जोड़ूंगा: विशेष रूप से सावधान रहें क्योंकि यह sysadmin अक्षम साबित हुआ है। बेहतर होगा जब आपकी पीठ को कवर किया जाएगा (और नहीं तो ) वह अच्छे के लिए सर्वर को पेंच करेगा।

— dr01

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

— टॉबी

ऐसा नहीं है कि दूसरे एडमिन को "बेवकूफ की तरह दिखने के लिए बनाया जा सकता है"। यह है कि दूसरे व्यवस्थापक ने कुछ मूर्खतापूर्ण किया। मैं केवल एक परिदृश्य के बारे में सोच सकता हूं, जिसके तहत मशीनों के बीच एक निजी कुंजी साझा की जानी चाहिए, और जहां एक ही नाम (राउंड-रॉबिन डीएनएस रिज़ॉल्यूशन आदि) के माध्यम से सर्वरों का एक पूल एक्सेस किया जाता है और उसी एसएसएच होस्ट कुंजी को प्रस्तुत करना चाहिए ताकि स्वचालित प्रक्रिया यह स्वीकार करेगी कि वे नाम हैं। और उस मामले में, एक ही व्यक्ति सभी सर्वरों का एक व्यवस्थापक होगा, और एक बाहरी पार्टी को शामिल किए बिना स्थानांतरण को संभाल लेगा।

— मोंटी हार्डर

@zwol मेरी नौकरी में, हमारे पास "कोई दोष नहीं" दर्शन है जो समझता है कि हम गलतियाँ करेंगे, लेकिन यह एक ही प्राथमिकता है कि एक ही गलती दो बार न करें। लेकिन एक ही गलती को दो बार नहीं करने के लिए, आपको यह जानना होगा कि यह एक गलती है, यही वजह है कि मैं ओपी को सुझाव देने वाले उत्तरों को वोट नहीं दे सकता कि अन्य व्यवस्थापक को बताए बिना चीजों को ठीक करें। मैंने गलती को 'आइडियल' कहने की बजाए आपके द्वारा बताए गए कारण के लिए व्यवस्थापक नामों को ठीक से कॉल करने के बजाय चुना । (लेकिन मैं निश्चित नहीं हूं कि आपके समापन के लिए पैतृक कला एक सार्थक अंतर को स्पष्ट करती है।)

— मोंटी हार्डर

@LightnessRacesinOrbit, मुझे संदेह है कि आपको "कूटनीति" के अर्थ की अधूरी समझ हो सकती है। क्या आपने इसे एक अच्छे शब्दकोश में साफ़ करने की कोशिश की है, जैसे कि वेबस्टर का तीसरा नया अंतर्राष्ट्रीय शब्दकोश?

— वाइल्डकार्ड

Answer 2

क्या मुझे केवल उस कुंजी को अनदेखा करना चाहिए, जो उसने मुझे भेजी है और उन्हें अपनी सार्वजनिक कुंजी उनके अधिकृत फ़ोल्डर में डालने के लिए कहूं?

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

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

Comments

और चूंकि ओपी के पास यह जानने का कोई तरीका नहीं है कि प्रशासन की मशीन कितनी सुरक्षित है (कहानी से, संभवतः बहुत असुरक्षित), उसे यह मान लेना चाहिए कि निजी कुंजी (या होगी) अन्य लोगों के लिए भी लीक है। ईमेल के माध्यम से एक निजी कुंजी भेजना infosec cluelessness के लिए सिर्फ एक बोनस तथ्य है।

— dr01

आप यह मान सकते हैं कि एक व्यवस्थापक जो उपयोगकर्ताओं को बनाने में सक्षम है, उसे आपको प्रतिरूपित करने के लिए आपकी निजी कुंजी की आवश्यकता नहीं होगी।

— मैक्स राइड

@MaxRied जगह में उचित सुरक्षा लॉग के साथ करना मुश्किल हो सकता है। आपकी निजी कुंजी के साथ उसे लॉग को मॉक करने की भी आवश्यकता नहीं है। यह आपके पासवर्ड बनाम आपके पासवर्ड को जानने की क्षमता को रीसेट करने जैसा है।

— दिमित्री ग्रिगोरीव

@DmitryGrigoryev वह हमेशा आपके अधिकृत_की फ़ाइल में एक और कुंजी जोड़ सकता है ...

— Max Ried

@MaxRied मैं /var/log/secureया इसी तरह की बात कर रहा था , मुझे पूरा यकीन है कि अंतरिक्ष चाल यह एक मूर्ख नहीं होगी।

— दिमित्री ग्रिगोरीव

Answer 3

मेरे लिए ऐसा लगता है कि व्यवस्थापक ने आपके लिए एक निजी / सार्वजनिक कुंजी जोड़ी उत्पन्न की, जिसने public_ को अधिकृत_की में जोड़ा और आपको निजी भेजा। इस तरह से आपको केवल सर्वर के साथ अपने ssh सत्र के लिए इस निजी कुंजी का उपयोग करना होगा। खुद को की-पेयर जेनरेट करने की जरूरत नहीं है या एडमिन को आपके संभावित रूप से भ्रष्ट (हमेशा सबसे खराब स्थिति: पी) निजी कुंजी को सार्वजनिक कुंजी भेजने की आवश्यकता है।

हालाँकि, मुझे आपके द्वारा भेजी गई निजी कुंजी को अनएन्क्रिप्टेड मेल के माध्यम से भरोसा नहीं होगा।

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

Comments

@ टॉबी उनके द्वारा निजी कुंजी भेजने के लिए केवल एक ही कारण हो सकता है कि वे अपने द्वारा उपयोग किए जा रहे उपकरणों को नहीं समझते हैं। और आप -iकमांड लाइन पर उपयोग कर सकते हैं कि किस निजी कुंजी का उपयोग करना है।

— कैस्परल्ड

@kasperd जिस कारण की मैं कल्पना कर सकता हूं, वह एक ओवरसाइज्ड sysadmin है जिसने यह निर्णय लिया है कि ईमेल पर एक निजी कुंजी भेजने के जोखिमों को कम-तकनीक वाले उपयोगकर्ताओं को समझाने की कोशिश करने की परेशानी से आगे निकल जाते हैं कि कैसे एक महत्वपूर्ण जोड़ी को ठीक से बनाने और भेजने के लिए सार्वजनिक कुंजी वापस।

— 12

महान बिंदु है कि आप इसे स्वयं ठीक कर सकते हैं। एक नई कीपेयर के लिए सार्वजनिक कुंजी स्थापित करने के लिए व्यवस्थापक की प्रतीक्षा करने की तुलना में इसे स्वयं करना बेहतर है। नो-नॉट-सीक्रेट प्राइवेट की का उपयोग करने से बचना कुछ भी मदद नहीं करता है; इससे पहले कि आप इसे प्राप्त करने से पहले इसका इस्तेमाल कर सकें और इसे हटा सकते हैं authorized_keys( इसे जोड़ने के बाद (अपने खुद के परीक्षण के बाद)।

— पीटर कॉर्ड्स

@mattdm यह ... पूरी तरह से तार्किक है, फिर भी भयावह है। एक व्यक्ति जो एक प्रमुख जोड़ी उत्पन्न नहीं कर सकता है और मुझे सार्वजनिक कुंजी भेज सकता है वह संभवतः एक निजी कुंजी के साथ बेहतर नहीं करने वाला है जो मैं उसे देता हूं।

— मोंटी हार्डर

@mattdm, काफी उचित है, लेकिन जैसा कि मैं उसे यह सब करने के लिए कहने के लिए था, मुझे यह विश्वास करना मुश्किल लगता है कि उसने सोचा कि मुझे नहीं पता कि ssh के साथ कैसे जुड़ना है। अगर कुछ भी कदम उसने उठाया तो अधिक भ्रमित था क्योंकि मुझे केवल सार्वजनिक कुंजी का उपयोग करने का मूल सामान्य तरीका पता है। : x

— टोबी