मेरे पास सर्वर ए और सर्वर बी (बैकअप) है, और मैं सोच रहा था, अगर कोई व्यक्ति सर्वर ए में टूट जाता है, तो क्या यह सर्वर बी में टूटने के लिए संभावित रूप से खतरनाक हो सकता है अगर मैंने ssh सार्वजनिक कुंजी का उपयोग करके पासवर्ड रहित लॉगिन कॉन्फ़िगर किया है?
मैं rsnapshot सेटअप करने का प्रयास कर रहा हूं।
धन्यवाद
जवाबों:
हां, यह पासवर्ड रहित SSH कुंजी के साथ समस्याओं में से एक है। यदि आप सर्वर A पर एक निजी कुंजी संग्रहीत करते हैं, जो आपको सर्वर B से कनेक्ट करने की अनुमति देता है, तो सर्वर A तक पहुँच प्रभावी रूप से सर्वर B तक पहुँच प्राप्त कर रहा है (रिवर्स रिवर्स सच नहीं है - सर्वर B तक पहुँच प्राप्त करने का परिणाम नहीं होगा सर्वर ए का तत्काल समझौता, यह मानते हुए कि आपके पास उस दिशा में पासवर्ड रहित लॉगिन की अनुमति देने के लिए एसएसएच कुंजी नहीं है।
इसे कम करने के लिए आप कुछ चीजें कर सकते हैं:
authorized_keysफ़ाइल में, अपनी प्रत्येक कुंजी के साथ उपसर्ग करें:command="<allowed command line here>",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty8-9 साल पहले मैंने सैकड़ों स्थानीय उपयोगकर्ताओं के साथ साझा उपयोगकर्ता वातावरण में काम किया था, और SSH कुंजी-आधारित लॉगिन अक्षम थे क्योंकि कुंजी पर पासवर्ड नीतियों को लागू करने का कोई तरीका नहीं था। जब तक आप परिदृश्य को पूरी तरह से नियंत्रित कर रहे हैं, आजकल SSH कुंजी निश्चित रूप से केवल पासवर्ड का उपयोग करने से बेहतर है।
हां, इंटरनेट पर अधिकांश गाइड पासवर्डलेस ssh को काम करने के लिए रोकते हैं, बजाय इसे सुरक्षित रूप से काम करने के। यह मार्गदर्शिका यह दिखाने का अच्छा काम करती है कि जोखिमों को कम करने के लिए क्या किया जा सकता है। मूल रूप से (लेख को उद्धृत करने के लिए):
dnssyncप्रत्येक मशीन पर एक उपयोगकर्ताcommand=और from=विकल्पauthorized_keysssh-agentतो दूसरी पासफ़्रेज़-कम कुंजी बनाने के बजाय उपयोग करेंSsh कुंजी के साथ कुछ समस्याएं हैं:
कुंजी को निरस्त करने का कोई केंद्रीकृत तरीका नहीं।
कुंजी पर पासवर्ड नीतियों को लागू करने का कोई तरीका नहीं है (क्या आपकी निजी कुंजी एन्क्रिप्ट की गई है, और यदि ऐसा है तो इसे एक अच्छे पासवर्ड के साथ एन्क्रिप्ट किया गया है?)।
ये समस्याएं हैं केर्बेरोस सॉल्व। यह दूसरों का परिचय देता है, हालांकि, इसे लागू करने के लिए अधिक जटिल है और तैनात करने और प्रबंधित करने के लिए एक वास्तविक उपयोगकर्ता प्रबंधन बुनियादी ढांचे की आवश्यकता होती है।
किसी भी मामले में, हालांकि ssh अधिकृत_कीप्स मॉरिस-वर्म प्रकार के हमलों के लिए अनुमति देते हैं , यह मील (प्रकाश-वर्ष) द्वारा अभी भी .r सेवाओं और टेलनेट से बेहतर है।
जिस किसी भी वातावरण में मैंने नियंत्रण किया है, मैं हमेशा सेवा खातों के लिए न्यूनतम संभव विशेषाधिकार के लिए एक वास्तविक स्टिकर रहा हूं।
इस मामले में, मैं यह सुनिश्चित करने का सुझाव दूंगा कि दूरस्थ सर्वर पर उपयोगकर्ता खाते को केवल एक छोटा, कसकर निर्धारित निष्पादन योग्य सेट चलाने की अनुमति है। आप इसे पूरा करने के लिए दूरस्थ पक्ष और sudo पर कई खातों का उपयोग कर सकते हैं।
इस मामले में भी, आप अभी भी स्थानीय विशेषाधिकार वृद्धि कीड़ों के अधीन हैं, इसलिए सावधानीपूर्वक रहें और सुरक्षा बगों पर सख्ती से नज़र रखें।