क्या निजी कुंजी सिंक करना एक अच्छा विचार है?

11

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

उस ने कहा, मैं अपने ~/.ssh/id_dsaबादल में डालने के बारे में काफी चिंतित हूं । जाहिर है, कोई भी सिस्टम पूरी तरह से सुरक्षित नहीं है। क्या कोई जानकार पार्टी, व्यावहारिक रूप से जोखिमों का आंकलन कर सकती है?

— Jjed
स्रोत

मैंने अपना जवाब अपडेट कर दिया है, उम्मीद है कि आप जोखिम की बेहतर समझ देंगे।

— ह्यूजेंस

6

उबंटू वन स्टोरेज को उपयोगकर्ता क्रिप्टोग्राफिक कुंजी के साथ एन्क्रिप्ट नहीं किया गया है

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

इसलिए मैंने अपने ~ / .shsh फ़ोल्डर को क्लाउड पर सिंक नहीं किया। जब तक आप एक एन्क्रिप्टेड कंटेनर सेट नहीं करते हैं जो तब क्लाउड पर भेज दिया जाता है, लेकिन तब ssh कुंजियों के लिए, यह हमेशा इतना आसान नहीं होता है। लेकिन मैं आपको अपने डेटा को एन्क्रिप्ट करने के तरीके अभी भी देता हूं:

अधिक जानकारी

उबंटू वन कनेक्शन के लिए एन्क्रिप्शन का उपयोग कर रहा है (जैसा कि वास्तव में कहा गया है), इसका मतलब है कि मूल रूप से डेटा को HTTPS के कुछ प्रकार से प्रेषित किया जाता है। आप ईटीएफ (इलेक्ट्रॉनिक फ्रंटियर फाउंडेशन) के सौजन्य से HTTPS का उपयोग करते हुए ईव्सड्रोपर को दिखाई देने वाले वास्तव में अच्छी तरह से किए गए एनीमेशन का उपयोग कर सकते हैं ।

EFF एनीमेशन पर HTTPS बटन पर क्लिक करके, आप ड्रॉपबॉक्स या उबंटू वन कंटेनर में अपनी SSH चाबियाँ डालते समय यह देख पाएंगे कि हर किसी को क्या दिखाई दे रहा है। जैसा कि एनीमेशन बताता है, site.com (जैसे one.ubuntu.com) पर कई व्यक्ति आपके डेटा (और कई और) को देख पाएंगे। यहां तक कि अगर आप अपने सभी ट्रैफ़िक को रूट करने के लिए टॉर जैसी किसी चीज़ का उपयोग करेंगे, तो भी इसका मतलब होगा कि site.com पर मौजूद लोग डेटा एक्सेस कर सकते हैं।

इसलिए आपको अपने कंप्यूटर को छोड़ने से पहले डेटा को एन्क्रिप्ट करना होगा। तो यह साइट पर एन्क्रिप्टेड में आता है। क्रेडेंशियल के साथ वे जिनके बारे में नहीं जानते हैं। बेशक, आपको एक मजबूत एन्क्रिप्शन तंत्र का उपयोग करना होगा ताकि यह साइट.कॉम पर लोगों के लिए इसे क्रैक करने के लिए बेहद धीमा हो जाए।

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

— हुय्गेंस
स्रोत

1

मैं अपने ~ / .shsh / id_dsa को क्लाउड में डालने के बारे में काफी उत्सुक हूं।

ठीक है, एक समाधान यह है कि मैं अपने ssh और gpg निजी कुंजी ड्रॉपबॉक्स के साथ क्या करता हूं: उन्हें एक संग्रह में एन्क्रिप्ट करें, और "कच्चे" मूल को हटा दें। जब भी जरूरत होती है, मैं अस्थायी रूप से इसे निकालता हूं और फिर जब इसे हटाता हूं।

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

आपके द्वारा बार-बार किए जाने वाले सामान के लिए जीवन को आसान बनाने के लिए (जैसे, gpg डिक्रिप्शन), आपके पास अस्थायी डिक्रिप्शन / उपयोग / विलोपन भाग को संभालने के लिए एक सरल बैश स्क्रिप्ट हो सकती है; इसे अस्थायी रूप से किसी भी सिंक डेमॉन को निष्क्रिय करना चाहिए ताकि निकाले गए कुंजी गलती से सिंक न हो।

— ish
स्रोत

1

आप बैकअप उपकरण डेजा-डुप के माध्यम से यू 1 पर अपनी चाबियाँ बचा सकते हैं। यदि आप एक पासवर्ड सेट करते हैं तो बैकअप फ़ाइलें U1 पर स्वचालित रूप से एन्क्रिप्ट की जाती हैं। मैन्युअल रूप से ऐसा करने की आवश्यकता नहीं है।

— Vosaxalo
स्रोत

1

जोखिम को परिभाषित करने के लिए अलग-अलग उपलब्ध मीट्रिक हैं, लेकिन आपको उस डेटा या सिस्टम के मूल्य को ध्यान में रखना होगा जिसे कुंजी एक्सेस दे सकती है। यदि कुंजी खो गई है, और कुछ इकाई इसका उपयोग प्राप्त कर सकती है, तो क्या समझौता किया जाएगा? क्या डर गोपनीय डेटा, डेटा हानि, एक प्रशासनिक या खाता स्तर, आदि से खातों से समझौता करने की संभावना है? यदि आप ऐसे डेटा को फिर से बना सकते हैं जो गोपनीय नहीं है, और यदि आपके पास गोपनीय डेटा सुरक्षित रूप से संग्रहीत है (जैसे, एन्क्रिप्ट किया गया), तो यह कम दबाव है। मुझे लगता है कि सिस्टम में अलग-अलग कमजोरियों के लिए वर्कअराउंड की गणना आपके ओवर-ऑल जोखिम को परिभाषित करने का हिस्सा है। व्यावहारिक रूप से, यह संभावना नहीं है कि आपके .id_rsa को संग्रहीत करना एक समस्या होगी, खासकर यदि आप कुछ अंतराल पर चाबियाँ घुमाते हैं। यह कई मान्यताओं पर निर्भर करता है, लेकिन फिर भी,

— Belacqua
स्रोत

0

सरल उपाय। की तरह। यदि आप USB फ्लैश ड्राइव जैसी किसी चीज का उपयोग नहीं कर सकते हैं, तो अपने SSH कुंजी पर पासफ़्रेज़ रखें। तत्काल दो-कारक प्रमाणीकरण (प्रकार)। आपको नई सार्वजनिक कुंजी अपलोड करने की भी आवश्यकता नहीं है।

— Hello71
स्रोत