SSH कीज़ को कैसे स्टोर करें?

Question

मैंने हाल ही में पासवर्ड के बजाय SSH कुंजी का उपयोग करना शुरू कर दिया है (निश्चित रूप से GitHub के लिए धन्यवाद), इसलिए कृपया ध्यान रखें कि मैं इस पूरी अवधारणा के लिए बहुत नया हूं। वर्तमान में मेरी चाबियां बस ~ / .ssh के नीचे हैं, लेकिन मुझे यकीन नहीं है कि यह एक अच्छा अभ्यास है। उदाहरण के लिए, यदि मेरे पास कई मशीनें हैं, तो मुझे अपनी निजी कुंजियों की नकल करने की आवश्यकता होगी, जो मुझे लगता है कि अवांछनीय है। या, अगर मेरा एचडीडी कपुट जाता है, तो मैं उन चाबियों को खो दूंगा, जो (मुझे लगता है) अवांछनीय है।

तो, SSH कुंजी को सुरक्षित रूप से, सुविधापूर्वक और मज़बूती से संग्रहीत करने पर सर्वोत्तम अभ्यास क्या हैं?

ऐसा लगता है कि स्मार्टकार्ड का उपयोग करना एक विकल्प है (देखें gpg / ssh कीज़ (लिनक्स) स्टोर करने के लिए स्मार्टकार्ड - मुझे इसकी आवश्यकता नहीं है? ), क्या यह सबसे अच्छा है?

अद्यतन: सवाल का कारण यह था कि कई सेवाएं (जैसे GitHub, AWS EC2) सेवा का उपयोग करने के लिए SSH कुंजी सेट करने के तरीके के बारे में गाइड प्रदान करती हैं, लेकिन कोई पृष्ठभूमि नहीं है (जैसे, यदि आपके पास पहले से ही एक कुंजी है तो क्या करें? ssh-keygen[1] द्वारा , सुरक्षा उपायों की क्या सिफारिश की जाती है)। और यह स्पष्ट नहीं है कि यह जानकारी वास्तव में महत्वहीन है, या आप इसे 'डिफ़ॉल्ट रूप से' जानने की उम्मीद कर रहे हैं।

इस बिंदु तक जवाब देने के लिए (लेकिन कृपया उन्हें पढ़ें, और यदि आपके पास जोड़ने के लिए कुछ है - तो कृपया करें): ऐसा लगता है कि इस मामले में यह ठीक है यदि आप अपनी निजी कुंजी ~ / .ssh में छोड़ देते हैं, जब तक कि आप। उन्हें अन्य लोगों से रखें; लेकिन यह सुनिश्चित करें कि आपके पास एक खो जाने पर (जो आमतौर पर मामला है) अपलोड करने के लिए सेवा को एक्सेस करने या नई कुंजी उत्पन्न करने का एक और तरीका है।

[१] कई कुंजियों के प्रबंधन के लिए GitHub मदद प्रदान करता था ।

Comments

वह लिंक टूटी हुई मदद

— KJ Price

@KJ मूल्य, इंटरनेट आर्काइव्स वेबैक मशीन के लिए धन्यवाद , पेज अभी भी ऑनलाइन उपलब्ध है, हालांकि इसके मूल लिंक पर नहीं। 2 सितंबर, 2011 को संग्रहीत पृष्ठ की एक प्रति मल्टीपल SSH कुंजियों में पाई जा सकती है ।

— चांदनी

Answer 1

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

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

इसके अलावा, अगर मेरा एचडीडी कपुट जाता है, तो मैं अपनी निजी कुंजी खो दूंगा, जो (मुझे लगता है) अवांछनीय है।

ज़रुरी नहीं; यदि आप अपनी निजी कुंजी खो देते हैं, तो बस एक नया जनरेट करें और संबंधित सार्वजनिक कुंजी अपलोड करें।

इसके लायक क्या है, आप सही हैं कि निजी कुंजी को डुप्लिकेट करना बहुत अवांछनीय है। आदर्श रूप से, एक फ़ाइल में एक निजी कुंजी उत्पन्न की जानी चाहिए ( ~/.ssh/id_rsaउदाहरण के लिए) और उस फ़ाइल को कभी नहीं छोड़ना चाहिए - अर्थात, इसे कभी भी कॉपी नहीं किया जाना चाहिए, स्थानांतरित नहीं किया जाना चाहिए, और विशेष रूप से एक नेटवर्क पर स्थानांतरित नहीं किया जाना चाहिए। (जैसे मैं उन्हें बैकअप से बाहर करता हूं) असममित प्रमाणीकरण प्रोटोकॉल की प्रकृति के कारण, आपको केवल अपनी निजी कुंजी दूसरों के हाथों से बाहर रखने के बारे में चिंता करने की आवश्यकता है। यदि आप थोड़ा ओवरबोर्ड जाते हैं और आप स्वयं इसका ट्रैक खो देते हैं, तो यह आम तौर पर बड़ी बात नहीं है। (यह असममित एन्क्रिप्शन निजी कुंजी, उदाहरण के लिए GPG कुंजी, जिसे आप शायद पकड़ना चाहते हैं) के साथ भ्रमित नहीं होना है।

Comments

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

— वृक्ष

@TREE: सही है, लेकिन मेरे अनुभव में यह एक सर्वर को खोजने के लिए असाधारण रूप से दुर्लभ है जो एक्सेस की कुछ वैकल्पिक विधि प्रदान नहीं करता है (या कम से कम SSH के माध्यम से एक अतिरिक्त सार्वजनिक कुंजी जोड़ने के बिना)।

— डेविड जेड

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

— एंटोन स्ट्रोगनॉफ

AWS निजी कुंजी के अलावा किसी अन्य प्रकार की पहुँच प्रदान नहीं करता है। आपको अपनी निजी कुंजी खो जाने के बाद पहुँच प्राप्त करने के लिए ड्राइव को डिस्कनेक्ट करना होगा और उसके चारों ओर मूर्ख बनाना होगा।

— असद सईदुद्दीन

ध्यान दें कि यदि आप सुरक्षा की एक और परत चाहते हैं तो आप अपनी निजी कुंजी पर पासवर्ड डाल सकते हैं।

— सूदो

Answer 2

यदि आप दोनों को चलाने के लिए एक ही उपयोगकर्ता खाते का उपयोग कर रहे हैं तो मैं आपके ब्राउज़र द्वारा ~ / .ssh / पठनीय जोड़ूंगा।

कोशिश करो! अपने घर की निर्देशिका में अपनी निजी कुंजी के लिए अपने ब्राउज़र को इंगित करें । मजा आता है।

इसलिए मैं दूसरे यूजर अकाउंट की होम डायरेक्टरी में ssh- कीज़ स्टोर करने की सलाह दूंगा।

पासफ़्रेज़ पर एक शब्द कुंजियों की सुरक्षा

• इन दिनों, गैर-यादृच्छिक पासवर्ड को क्रैक करना सुपर फास्ट है। हैश बिल्ली की जाँच करें
  • (हालांकि यादृच्छिक और लंबे 12+ चार पासवर्ड अभी भी काफी समय तक बल को रोकते हैं)
  • तो जब तक आप अच्छे लंबे पासफ़्रेज़ का उपयोग करते हैं, तब तक एईएस एन्क्रिप्टेड ssh कुंजियाँ भविष्य के लिए अप्राप्य होती हैं। गीथूब सिफारिशें देखें
• तो कुछ वेबसाइट आपके कुंजी w / o जावास्क्रिप्ट को अनुमान लगा सकती हैं। और फिर कुंजी को ऑफलाइन ऑफ़लाइन करें।
• और ब्राउज़र आपके क्लिपबोर्ड w / JS में भी देख सकते हैं। इसलिए बहुत लंबे पासफ़्रेज़ की प्रतिलिपि बनाना भी आपको अधिक परिष्कृत जावास्क्रिप्ट हमलों से जोखिम में डालता है।

look_at_keys.html

 9 <HTML>
10 <HEAD>
11 <TITLE>look at keys</TITLE>
12 </HEAD>
13 <FRAMESET cols="20%, 80%">
14   <FRAMESET rows="100, 200">
15       <FRAME src="/Users/yourname/.ssh/stuff.pem">
16       <FRAME src="blah.html">
17   </FRAMESET>
18   <FRAME src="contents_of_frame3.html">
19 </FRAMESET>
20 </HTML>

Comments

स्पष्ट होने के लिए, क्योंकि ब्राउज़र आपकी निजी कुंजी को पढ़ सकता है, जिसका अर्थ यह नहीं है कि ब्राउज़र में चलने वाली वेबसाइट कर सकती है।

— Ajedi32

लेकिन, यदि आप ब्राउज़र की प्रक्रिया में एक प्रक्रिया को इंजेक्ट करते हैं। फिर आप ब्राउजर का भी नियंत्रण ले सकते हैं। इसलिए यह तर्क पूरी तरह से मान्य है।

— बिगसैक

लेकिन फिर आपको उस प्रक्रिया को हैक करना होगा जो आपके ब्राउज़र की प्रोसेसिंग यूनिट के प्रोसेस रजिस्टर में प्रक्रियाओं को इंजेक्ट करती है।

— स्किड कड़ा

Answer 3

एक्सटेंशन के साथ KeePass2 ( http://keepass.info/ ) नाम का एक बहुत अच्छा उपकरण है ( http://lechnology.com/software/keeagent/ )

आप वहां Passwords, SSH Keys, और बहुत कुछ स्टोर कर सकते हैं (आधिकारिक KeePass पेज पर बहुत अधिक उपयोगी एक्सटेंशन हैं)
यदि आप अपने SSH कीज़ के साथ ऑटोमैटिकली लॉगिन करना चाहते हैं, तो आपको KeeAgent के साथ PuTy, Pageant और KeePass को इंस्टॉल करना होगा। यदि आप इसे सही तरीके से कॉन्फ़िगर कर रहे हैं, तो आपको न केवल PuTTY, Pageant या FileZilla में कुंजियों को सेटअप करना होगा।

मैं इसे खुद इस्तेमाल करता हूं और मैं इसके बारे में बहुत खुश हूं। मेरे पास 30 से अधिक वीपीएस और रूट सर्वर हैं जिनमें एक निश्चित एसएसएच कीज़ की एक निश्चित राशि और केवल एक चीज है जो मुझे खुले केईपास (इसकी प्राथमिक पासवर्ड सुरक्षित नहीं है) और फिर मुझे कंसोल में अपना पासफ़्रेज़ टाइप करने की आवश्यकता है।

Answer 4

मैं निजी कुंजियाँ संग्रहीत करने की सलाह दूंगा:

• ऑफ़लाइन (क्लाउड में नहीं)
• एक से अधिक स्थानों पर
• इससे संबंधित किसी भी चीज़ से, जैसे आपके एन्क्रिप्ट किए गए डेटा के लिए एक कुंजी, इसे डेटा से अलग स्थान पर संग्रहीत करें

मैं कहता हूँ, सबसे अच्छी जगह होगी:

• एक बाहरी हार्ड ड्राइव
• एक फ्लैश कुंजी
• एक कंप्यूटर इंटरनेट में प्लग नहीं है

इससे भी बेहतर, बस इसे प्रिंट करें, और इसे फायर प्रूफ में सुरक्षित रखें।

Comments

सुरक्षा / सर्वोत्तम व्यवहार व्यावहारिकता के साथ काम करते हैं। यदि कोई सुरक्षा रणनीति किसी सिस्टम का उपयोग करने की क्षमता में बाधा उत्पन्न करती है, तो यह उपयोगकर्ता द्वारा हमलावर के बजाय बाईपास होने वाला है।

— zaTricky

Answer 5

मेरे पास एक टार फाइल है जिसमें मेरा उपयोगकर्ता dir सेटअप (.bashrc, .sh / और अन्य कॉन्फिग फाइल) है जिसे मैं एक सुरक्षित स्थान पर रखता हूं। जब मुझे कहीं भी एक नया शेल खाता मिलता है, तो मैं उसमें टार फाइल खोल देता हूं।

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

निजी तौर पर, मैं बस हर जगह अपने .ssh / सामान की नकल करने के लिए सहज हूं (यह नियमित एसएच कुंजी द्वारा भी इसका मतलब है, तुरंत एसएस एक्सेस प्राप्त करता है, क्योंकि यह पहले से ही अधिकृत_की फ़ाइल में है)।

Comments

मुझे लगता है, एक USB छड़ी पर चारों ओर लटका हुआ एन्क्रिप्टेड ~ /। Ssh हार्डवेयर विफलता के मामले में नई कुंजी को उत्पन्न करने और अपलोड करने की आवश्यकता से बचाएगा। हालाँकि, चूंकि बहुत कम सर्वर हैं जिनका उपयोग करने के लिए मैं SSH कुंजियों का उपयोग करता हूं (और बहुत कम मशीनें जिनसे मैं जुड़ता हूं), नई कुंजियों को बनाने से बहुत अधिक ओवरहेड नहीं होगा।

— एंटोन स्ट्रोगनॉफ

यह पाठ्यक्रमों के लिए घोड़े हैं और इस बात पर निर्भर करते हैं कि आप कुंजियों का उपयोग क्यों करते हैं। मुझे पहले से ही एन्क्रिप्ट किए गए SSH लिंक पर ssh निजी कुंजी को कॉपी करने में कोई समस्या नहीं दिख रही है। लेकिन अगर आप लक्ष्य मशीन पर भरोसा नहीं करते हैं और यह नहीं जानते हैं कि रूट एक्सेस किसके पास है, तो आपको उस सर्वर पर कुछ भी नहीं रखना चाहिए जिसे आप खो नहीं सकते।

— EightBitTony

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

— कोडगुइ ००7

आप ssh पर ssh-Agent को अग्रेषित कर सकते हैं। इस तरह आपको सर्वर पर निजी कुंजी संग्रहीत करने या नेट पर अपना पासफ़्रेज़ भेजने की आवश्यकता नहीं है। stackoverflow.com/questions/12257968/…

— कोडगुवाई 007

Answer 6

आप एक एन्क्रिप्टेड विभाजन के अंदर एक अलग निर्देशिका में अपनी ssh कुंजी स्टोर कर सकते हैं। फिर आप उस निर्देशिका की ओर इशारा करते हुए ssh का उपयोग कर सकते हैं -i:

ssh -i identity_file [e-mail]

पूर्ण विवरण ( man ssh):

-य पहचान_फाइल

ऐसी फ़ाइल का चयन करता है जिससे सार्वजनिक कुंजी प्रमाणीकरण के लिए पहचान (निजी कुंजी) पढ़ी जाती है। डिफ़ॉल्ट प्रोटोकॉल संस्करण 1 के लिए ~ / .ssh / पहचान है, और ~ / .sh / id_dsa, ~ / .sh / id_ecdsa, ~ / .sh / id_ed25519 और ~ / .ssh / id_rsa के लिए प्रोटोकॉल संस्करण 2. पहचान फ़ाइलें हो सकती हैं। कॉन्फ़िगरेशन फ़ाइल में प्रति-होस्ट आधार पर भी निर्दिष्ट किया जाना चाहिए।
एकाधिक -i विकल्प (और कॉन्फ़िगरेशन फ़ाइलों में निर्दिष्ट कई पहचान) होना संभव है। यदि प्रमाणपत्र प्रमाणपत्र के द्वारा कोई प्रमाण पत्र स्पष्ट रूप से निर्दिष्ट नहीं किया गया है, तो ssh पहचान फ़ाइल नाम के साथ -cert.pub द्वारा प्राप्त फ़ाइल नाम से प्रमाणपत्र जानकारी को लोड करने का भी प्रयास करेगा।

सुरक्षा के लिए मेरा दृष्टिकोण यह है कि मैं जानकारी को निजी और सामान्य में विभाजित करता हूं। मैं अपने पूरे होम विभाजन को एन्क्रिप्ट नहीं करना चाहता, इसीलिए मैं गुप्त फाइलों (जैसे उन ~/.ssh) को एक एन्क्रिप्टेड विभाजन में कॉपी करता हूं ।

मुझे लगता है कि यह कुछ अधिक कुशल सुरक्षा देता है, क्योंकि मैलवेयर ~ / .shsh में कुछ भी नहीं खोजेगा, और शायद यह उस स्थान को खोजने के लिए आपके पूरे सिस्टम या शेल प्रोफाइल को स्कैन नहीं करेगा।

-F configfile 

फ़ाइल को कॉन्फ़िगर करने के लिए पथ सेट करता है।

पीएस मैं एक उपनाम बनाऊंगा alias ssh='ssh -i ... -F ...'और इसे आपके प्रोफ़ाइल में डालूंगा।

PPS मैंने अभी तक इसकी जांच नहीं की है, और मुझे नहीं पता कि अन्य प्रोग्राम (जैसे git) इन ssh सेटिंग्स के साथ कैसे काम करेंगे।