सर्वर व्यवस्थापक से एक निजी कुंजी प्राप्त करना: ठीक है या नहीं?


20

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


17
एक के लिए खराब सुरक्षा स्वच्छता। सर्वर व्यवस्थापक को बेहतर पता होना चाहिए, और बाहरी स्रोतों से निजी कुंजी प्राप्त करने की अपेक्षा करने के लिए "प्रशिक्षण" उपयोगकर्ताओं को नहीं होना चाहिए।
1892 में wmorrell

1
वह किसे और किसे दे रहा है? हमेशा सोचें, क्या सबसे बुरा हो सकता है?
मैकेंज़्म

1
मुझे नहीं लगता कि यह इतना बुरा है। नीचे एक सादृश्य (एरिक टावर्स) उपयोगकर्ता को "प्रारंभिक पासवर्ड" देने के साथ जिसे फिर तुरंत बदलने की आवश्यकता है, अच्छा है। व्यक्तिगत अनुभव से बोलते हुए, यह बताते हुए कि उपयोगकर्ताओं के लिए 100 वीं बार क्या चाबियाँ हैं, थोड़ा थकाऊ हो सकता है - व्यवस्थापक अभी भी मानव है। आपके लिए निजी कुंजी देना आलसी है - हाँ, लेकिन कुछ भी आपको इसे स्वयं को बदलने से रोक नहीं सकता है। संक्षेप में, जब उसने s / s को आपके पास भेजा है, तो आपको फिर से sysadmin को परेशान करने की आवश्यकता नहीं है (जब तक कि उन्होंने फ़ाइल पर लिखने की अनुमति बंद करने का विकल्प नहीं चुना है ... तब, उन्हें परेशान करें)।
रे

@matthiash यह प्रश्न इस साइट पर फिट बैठता है लेकिन, एक FYI के रूप में, अन्य सुरक्षा प्रश्नों के लिए एक सूचना सुरक्षा साइट है
Topher

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

जवाबों:


23

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

यह तथ्य कि कोई अन्य व्यक्ति आपको एक निजी कुंजी प्रदान करता है, यह स्वचालित रूप से समझौता करता है। (आप नहीं जानते कि क्या अन्य प्रशासन के पास अभी भी एक प्रति है जिसका उपयोग आपको प्रतिरूपण करने के लिए किया जा सकता है।)


4
चलो सर्वर व्यवस्थापक से सबसे अच्छा मान लेते हैं और यह मानते हैं कि वह, एक नया कीपर उत्पन्न करना बेहतर है, क्योंकि वह उपयोगकर्ता पर भरोसा नहीं करेगा कि उसके पास एक निजी कुंजी नहीं है। हो सकता है कि सर्वर व्यवस्थापक सोचता हो, कि उपयोगकर्ताओं की निजी कुंजी बहुत पुरानी है और शायद पिछले कुछ वर्षों में समझौता हो गया है। यह U2F के साथ समान है, जहां कंसोर्टियम या विक्रेता उपयोगकर्ताओं को चाबियाँ बनाने के लिए भरोसा नहीं करते हैं, यही कारण है कि U2F डिवाइस पूर्व-निर्मित कुंजी के साथ आते हैं!
कॉर्नेलिनक्स

8
व्यवस्थापक को उपयोगकर्ता को एक निजी कुंजी बनाने और सुरक्षित करने में मदद करनी चाहिए।
एलेक्स

1
तुम पूर्ण रूप से सही हो। लेकिन अक्सर कंप्यूटर के साथ मनुष्यों के साथ प्रवेश बेहतर होता है, -)
कॉर्नेलिनक्स

7
व्यवस्थापक वैसे भी आपको प्रतिरूपण कर सकता है।
user253751

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

10

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

आप अपनी अधिकृत कुंजियों को अपडेट करने, और अपनी कुंजी जोड़ने और प्रदान की गई कुंजी को हटाने के लिए आपके द्वारा प्रदान की गई कुंजियों से लिख सकने वाली विशेषाधिकार का उपयोग करने में सक्षम हो सकते हैं।


3
वास्तव में, व्यवस्थापक उपयोगकर्ता से उनके पहले उपयोग के दौरान उनकी कुंजी को बदलने की अपेक्षा कर सकता है, प्रशासनिक रूप से उत्पन्न पहले पासवर्ड के साथ।
एरिक टॉवर्स ने

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

@EricTowers है कि है संभव समकालीन SFTP के साथ की आवश्यकता होती है (या यहां तक कि SSH, जब तक आप एक साथ अपने आप को पक्की सड़क कुछ करने को तैयार हैं) कार्यान्वयन?
एक CVn

यह उत्तर यह धारणा देता है कि sftp पर कार्रवाई एक लॉग में कहीं हस्ताक्षरित होती है और उस कुंजी द्वारा सुरक्षित समाप्त होती है। यह बस ऐसा नहीं है, एक व्यवस्थापक कुंजी या कुंजी का उपयोग किए बिना भी लॉग के साथ छेड़छाड़ कर सकता है।
जेम्सरैन

1
@marcelm: एक कारण है कि मैंने कहा "अक्सर आवश्यक", "हमेशा सभी परिस्थितियों में बिल्कुल अनिवार्य नहीं अपवाद नहीं"। जैसा कि कोई करता है, वास्तव में, पासवर्ड हैश, और सार्वजनिक कुंजी को नियमित रूप से अनुरोध (और स्वीकार) करता है, मुझे पता है कि किसी को सार्वजनिक कुंजी की तुलना में हैश पासवर्ड (सुरक्षित नमक और सब कुछ के साथ) प्रदान करने के लिए किसी को प्राप्त करना बहुत अधिक बाधा है। यदि आपके पास SSH क्लाइंट है, तो आपके पास एक महत्वपूर्ण पीढ़ी का उपकरण है। cryptइसके कई मनोरंजक रूपों में कॉलिंग (2) में सक्षम कुछ के लिए नहीं कहा जा सकता है ।
वूमबल
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.