आरएसए-एसएचए डिजिटल हस्ताक्षर के लिए समर्थन को अक्षम करने के साथ ओपनएसएसएच 8.8 का विमोचन

ओपनएसएसएच 8.8 की रिलीज प्रकाशित की गई है, जो एसएसएच 2.0 और एसएफटीपी प्रोटोकॉल का उपयोग करके काम करने के लिए क्लाइंट और सर्वर का एक खुला कार्यान्वयन है। यह रिलीज़ SHA-1 हैश ("ssh-rsa") के साथ RSA कुंजियों पर आधारित डिजिटल हस्ताक्षरों का उपयोग करने की क्षमता को डिफ़ॉल्ट रूप से अक्षम करने के लिए उल्लेखनीय है।

"एसएसएच-आरएसए" हस्ताक्षरों के लिए समर्थन की समाप्ति किसी दिए गए उपसर्ग के साथ टकराव के हमलों की बढ़ी हुई दक्षता के कारण होती है (टकराव को चुनने की लागत लगभग $ 50 हजार अनुमानित है)। अपने सिस्टम पर ssh-rsa के उपयोग का परीक्षण करने के लिए, आप ssh के माध्यम से "-oHostKeyAlgorithms=-ssh-rsa" विकल्प से कनेक्ट करने का प्रयास कर सकते हैं। SHA-256 और SHA-512 हैश (rsa-sha2-256/512) के साथ RSA हस्ताक्षरों के लिए समर्थन, जो OpenSSH 7.2 के बाद से समर्थित है, अपरिवर्तित रहता है।

ज्यादातर मामलों में, "ssh-rsa" के लिए समर्थन बंद करने के लिए उपयोगकर्ताओं से किसी भी मैन्युअल कार्रवाई की आवश्यकता नहीं होगी, क्योंकि OpenSSH में पहले से ही डिफ़ॉल्ट रूप से UpdateHostKeys सेटिंग सक्षम थी, जो स्वचालित रूप से ग्राहकों को अधिक विश्वसनीय एल्गोरिदम में स्थानांतरित कर देती है। माइग्रेशन के लिए, प्रोटोकॉल एक्सटेंशन "[ईमेल संरक्षित]", प्रमाणीकरण के बाद, सर्वर को क्लाइंट को सभी उपलब्ध होस्ट कुंजियों के बारे में सूचित करने की अनुमति देता है। क्लाइंट साइड पर ओपनएसएसएच के बहुत पुराने संस्करणों के साथ होस्ट से कनेक्ट होने के मामले में, आप चुनिंदा रूप से ~/.ssh/config में जोड़कर "ssh-rsa" हस्ताक्षर का उपयोग करने की क्षमता वापस कर सकते हैं: होस्ट पुराना_होस्टनाम HostkeyAlgorithms +ssh-rsa PubkeyAcceptedAlgorithms + एसएसएच-आरएसए

नया संस्करण sshd के कारण होने वाली सुरक्षा समस्या को भी हल करता है, जो OpenSSH 6.2 से शुरू होती है, AuthorizedKeysCommand और AuthorizedPrincipalsCommand निर्देशों में निर्दिष्ट आदेशों को निष्पादित करते समय उपयोगकर्ता समूह को ठीक से आरंभ नहीं करता है। इन निर्देशों को एक अलग उपयोगकर्ता के तहत कमांड चलाने की अनुमति देनी चाहिए थी, लेकिन वास्तव में उन्हें sshd चलाते समय उपयोग किए जाने वाले समूहों की सूची विरासत में मिली। संभावित रूप से, यह व्यवहार, कुछ सिस्टम सेटिंग्स की उपस्थिति में, लॉन्च किए गए हैंडलर को सिस्टम पर अतिरिक्त विशेषाधिकार प्राप्त करने की अनुमति देता है।

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

स्रोत: opennet.ru