एक ही SSH सर्वर कुंजियों के साथ कई डिवाइस होना कितना बुरा है?

Question

मैं एक एम्बेडेड डिवाइस पर काम कर रहा हूं जो FreeBSD और SSH चलाता है।

जैसा कि आप जानते हैं, sshd को सर्वर कीज का एक सेट बेतरतीब ढंग से उत्पन्न करना पसंद है जब यह पहली बार बूट होता है। समस्या यह है कि हम उत्पाद को केवल-पढ़ने के लिए एसडी कार्ड फाइल सिस्टम (गैर-परक्राम्य) के साथ शिपिंग करेंगे।

मेरे दो विकल्प जैसे ही मैं उन्हें देखता हूं:

• सभी उपकरणों पर समान sshd सर्वर कुंजियों को शिप करें
• एक मेमोरी फ़ाइल सिस्टम को माउंट करें और प्रत्येक बूट पर सर्वर कीज़ उत्पन्न करें (धीमी ...)

क्या सभी उपकरणों पर एक ही सर्वर कीज़ को शिप करना एक बड़ी सुरक्षा समस्या है? ये आइटम सीधे इंटरनेट पर नहीं होंगे। कभी-कभी एक ही व्यक्ति और एक ही नेटवर्क के स्वामित्व वाले कई उपकरण होंगे।

अधिकांश समय डिवाइस इंटरनेट से कनेक्ट नहीं होगा।

एसएसएच के साथ लॉगिंग सामान्य ऑपरेशन का हिस्सा नहीं है। यह ज्यादातर प्रोग्रामर और तकनीशियनों की सुविधा के लिए है। ग्राहक SSH के साथ डिवाइस में लॉग इन नहीं करेंगे।

कई हार्डवेयर उपकरणों पर समान सर्वर कुंजियों का उपयोग करने के क्या नियम हैं?

PS कोई कृपया इंटरनेट-ऑफ़-थिंग्स टैग बना सकता है?

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

मुझे पता है कि यह शायद एक बुरा विचार है। मैं जानना चाहता हूं कि वास्तव में यह एक बुरा विचार क्यों है हालांकि मैं ट्रेडऑफ को समझ सकता हूं।

Comments

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

— हारून

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

— NXT 18

सभी उपकरणों पर एक ही उपयोगकर्ता नाम / पासवर्ड का उपयोग करना एक बहुत बुरा विचार है। वे सार्वजनिक कुंजी प्रमाणीकरण के लिए उपयोग की जाने वाली निजी कुंजी की तुलना में जानवर के बल पर आसान हैं। यहां तक ​​कि अगर इन वंचितों को सीधे इंटरनेट से जुड़ा हुआ नहीं माना जाता है, तो कोई भी इसे करेगा। और अगर "सीधे नहीं जुड़े" का अर्थ है NAT, तो वे पर्याप्त जुड़े हुए हैं ...

— Tero Kilkanen

SSH कुंजी साझा करने का अर्थ है कि कोई व्यक्ति जो किसी एक डिवाइस पर निजी कुंजी तक पहुंच सकता है, वह इन सभी उपकरणों का उपयोग कर सकता है।

— user253751

हालांकि यह एक दिलचस्प सवाल है, मुझे इसके बारे में कुछ भी नहीं दिखता है जो सिस्टम एडमिनिस्ट्रेशन से संबंधित है, और इस प्रकार सर्वर फॉल्ट के लिए ऑफ-टॉपिक है। आप एक एम्बेडेड डिवाइस के लिए डिबगिंग / डायग्नोस्टिक इंटरफ़ेस डिज़ाइन करने के बारे में पूछ रहे हैं जो आप शिपिंग कर रहे हैं, न कि एक इंटरफ़ेस जो sysadmins के लिए प्रासंगिक होगा। इस प्रश्न को सूचना सुरक्षा में स्थानांतरित किया जा सकता है ।

— २००:

Answer 1

एसडी कार्ड या अन्य रीड-ओनली मीडिया पर होस्ट-विशिष्ट डेटा जैसे ssh होस्ट कीज़ को संग्रहीत करने के बजाय, आप इसे NVRAM में स्टोर कर सकते हैं, जो कि एक एम्बेडेड सिस्टम पर है। आपको बूट समय पर कुंजियों को संग्रहीत करने और पुनः प्राप्त करने के लिए कुछ कस्टम स्क्रिप्टिंग करने की आवश्यकता होगी, लेकिन स्क्रिप्ट हर डिवाइस के लिए बिल्कुल समान होंगी।

Answer 2

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

दूसरी ओर, प्रत्येक बूट पर कुंजियों को पुनर्जीवित करते हुए, ग्राहकों पर एक चेतावनी भी ट्रिगर करेगा।

संदर्भ के लिए, से man ssh(1):

sshस्वचालित रूप से बनाए रखता है और कभी भी इसके साथ प्रयोग किया गया है सभी होस्ट के लिए पहचान युक्त एक डेटाबेस की जाँच करता है। होस्ट कुंजियाँ ~/.ssh/known_hostsउपयोगकर्ता के होम डायरेक्टरी में संग्रहीत की जाती हैं । इसके अतिरिक्त, फ़ाइल /etc/ssh/ssh_known_hostsस्वचालित रूप से ज्ञात मेजबानों के लिए जाँच की है। किसी भी नए होस्ट को स्वचालित रूप से उपयोगकर्ता की फ़ाइल में जोड़ा जाता है। यदि किसी होस्ट की पहचान कभी भी बदल जाती है, तो sshइसके बारे में चेतावनी देता है और सर्वर के स्पूफिंग या मैन-इन-द-मिडिल हमलों को रोकने के लिए पासवर्ड प्रमाणीकरण को अक्षम करता है, जो अन्यथा एन्क्रिप्शन को दरकिनार करने के लिए उपयोग किया जा सकता है। StrictHostKeyCheckingविकल्प मशीनों जिसका होस्ट कुंजी ज्ञात नहीं है या बदल गया है करने के लिए लॉगिन नियंत्रित करने के लिए इस्तेमाल किया जा सकता।

Comments

मुझे समझ में नहीं आता कि वे केवल एक बार (प्रत्येक डिवाइस पर, पहले बूट पर) क्यों नहीं उत्पन्न कर सकते हैं (फिर जब तक उन्हें हटा नहीं दिया जाता)?

— djsmiley2k - CoW

पूरी तरह से उल्लेखनीय। लेकिन ओपी बताता है कि वह चाहता है: 'एक मेमोरी फाइल सिस्टम को माउंट करें और प्रत्येक बूट पर सर्वर कीज उत्पन्न करें।' तो मेरा जवाब है कि मानता है।

— डेवड

आह, मुझे याद आया कि जब मैंने इसे पहली बार पढ़ा था।

— djsmiley2k -

Answer 3

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

यह निम्नलिखित की तरह मानव-में-मध्य हमलों की अनुमति देगा:

1. एक उपयोगकर्ता आपके डिवाइस से प्राप्त निजी कुंजी के साथ एक एसएसएच सर्वर सेट करता है और उस आईपी पते को आपके तकनीशियन को देता है।
2. आपका तकनीशियन SSH कनेक्शन पर रूट पासवर्ड इनपुट करता है।
3. उपयोगकर्ता अब रूट पासवर्ड जानता है जो आपके सभी उपकरणों के लिए मान्य है।

हालाँकि, आपको पहली बार रूट पासवर्ड का उपयोग नहीं करना चाहिए, इसके बजाय प्रमाणीकरण के लिए ssh कुंजियों का उपयोग करें। यदि आप केवल LAN से लॉग ऑन करते हैं तो साझा सर्वर कुंजियों का प्रभाव बहुत कम है ।

एसएसएच आगे गोपनीयता भी प्रदान करता है, इसलिए एक हमलावर को चाबियाँ से लाभ के लिए एक झूठे सर्वर को स्थापित करने में सक्षम होना चाहिए; निष्क्रिय रूप से यातायात को सूँघने से इसे डिक्रिप्ट करने की अनुमति नहीं होगी।

Comments

यह हास्यास्पद है कि हमारी पूर्व धारणाएं हमें (मुझे) अंधा कैसे कर सकती हैं। एसडी-कार्ड एक पैनल के पीछे की इकाई के अंदर होता है और एक सर्किट बोर्ड के नीचे होता है, इसलिए मेरे साथ ऐसा कभी नहीं हुआ कि कोई इसे बाहर निकाले। हालाँकि, आप सही हैं, यह पूरी तरह से एक पेचकश के साथ किसी के लिए भी सुलभ है। सिस्टम की भौतिक सुरक्षा पर विचार करने के लिए अनुस्मारक के लिए धन्यवाद।

— NXT

WRT # 2, रूट पासवर्ड को SSH कनेक्शन पर नहीं भेजा जाना चाहिए। यह टर्मिनल क्लाइंट में इनपुट होना चाहिए, और एक प्रमाणीकरण प्रोटोकॉल के स्थानीय आधे हिस्से के लिए उपयोग किया जाता है जो गुप्त ("ज्ञान प्रमाण") को प्रसारित किए बिना गुप्त कब्जे को साबित करता है। यहां तक ​​कि दशकों पुरानी प्रणालियां पासवर्ड का हैश भेजना जानती थीं न कि खुद पासवर्ड। चुनौती / प्रतिक्रिया प्रोटोकॉल में एक नॉनस शामिल करें, और हमलावर को न तो मूल पासवर्ड पता है और न ही कोई टोकन जिसका उपयोग उसकी जगह पर किया जा सके।

— बेन Voigt

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

— jpa

Answer 4

मैं इस डरावने में पढ़ा! मैं, जिन्होंने एक ही ssh होस्ट कुंजी के साथ एक ही क्लस्टर में कई मशीनें की हैं, कभी भी ऐसा करने की हिम्मत नहीं करेंगे। किसी भी परिस्थिति में ssh होस्ट कुंजी साझा करने के लिए व्यवस्थापकों के विभिन्न सेटों के साथ मशीनों की अनुमति न दें। जब आप अपनी सुरक्षा में कमी के लिए तैनात हो जाते हैं तो यह रास्ता पागलपन और चीखने वाला आतंक है।

देखो, मैं तुमसे सच कहता हूं, वह जो एक उपकरण से समझौता करता है, उन सभी से समझौता करता है। एक बार प्राप्त करने के बाद, बुरे लोगों से अपेक्षा करें कि वे एक से दूसरे स्थान पर कूदेंगे और सुरक्षा वापस लुढ़क जाएगी क्योंकि यह पतले कागज थे।

Comments

क्या आप इस बात पर विस्तार से बता सकते हैं कि एक हमलावर अन्य उपकरणों से समझौता करने के लिए एक चोरी किए गए सर्वर निजी कुंजी का उपयोग कैसे करेगा?

— jpa

@jpa: पासवर्ड को इंटरसेप्ट करके और चुराने के द्वारा होस्ट कीज़ के लिए, साथ ही, यह सेटअप यूजर कीज़ के लिए भी यही काम करता है।

— joshudson

Answer 5

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

आप या तो सभी उपकरणों को एक ही कुंजी के साथ जहाज कर सकते हैं, यह मानते हुए कि आपने "डिबग" मोड को संरक्षित किया है ताकि डिवाइस को हैक करने की कोशिश कर रहे किसी व्यक्ति द्वारा इसे दूरस्थ रूप से ट्रिगर नहीं किया जा सके।

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

Comments

मुझे यह विचार पसंद है।

— NXT

Answer 6

आपके पास मौजूद बाधाओं के आधार पर एक नमूना हमला परिदृश्य है:

यदि आपके उपकरण हैं, तो उदाहरण के लिए रास्पबेरी पाई कहें। अगर मैं ऊपर जाता हूं और एक से एसडी कार्ड को हिलाता हूं, तो मैं एसडी कार्ड को अपने कंप्यूटर में चिपका सकता हूं, sshd कुंजी ढूंढता हूं और कॉपी करता हूं कि हर जगह मैं चाहता हूं। शायद मैं अपना रास्पबेरी पाई और एक यूएसबी ईथरनेट कार्ड हड़प लूं। अब मैं एक लक्ष्य डिवाइस के बीच और जहाँ भी वे जा रहे हैं और ssh कनेक्शन के लिए निगरानी रख सकते हैं। जब मैं देखता हूं कि लक्ष्य डिवाइस एक ssh कनेक्शन बनाने की कोशिश कर रहा है, तो मैं यह करता हूं:

(target) <---> (my evil sshd <--> decrypted traffic <--> ssh) <---> (real server)
                                       |
                                       V
                                    log file

ओह, वह क्या है? आपका पासवर्ड "मुझे बिल्लियाँ पसंद हैं"? लड़का, यह एक दिलचस्प ईमेल है जिसे आपने अपनी पत्नी को भेजा है। मुझे यकीन है कि यह और भी दिलचस्प होगा अगर वह इस ईमेल को पढ़ती है जिसे आपने अपने अगले दरवाजे पड़ोसियों की पत्नी को भेजा है।

संभावनाएं अनंत हैं । और लक्ष्य कभी पता नहीं चलेगा, क्योंकि sshd कुंजी वास्तविक सर्वर पर पाए जाने वाले के समान है। आपके डिवाइस को मिलने वाली सुविधाओं की भौतिक सुरक्षा के आधार पर, यह अविश्वसनीय रूप से तुच्छ हो सकता है। यह मत करो।

इसके बजाय, वही करें जो आप पहले से ही प्रस्तावित कर रहे हैं लेकिन उसे ठीक कर लें । अपनी छवि लिखने से पहले कुछ इस तरह से चलाएं:

ssh-keygen -f some-new-server
cp some-new-server /path/to/the/mounted/image/sshd/key
cp some-new-server.pub /path/to/the/mounted/image/sshd/key.pub

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

Comments

यदि किसी के पास आपके हार्डवेयर की भौतिक पहुँच है और आप आराम से डेटा को एन्क्रिप्ट करने में विफल रहते हैं तो सभी दांव बंद हो जाते हैं।

— user9517