SSH कनेक्शन स्थापना एल्गोरिथम

(लेख का प्रारंभिक शीर्षक "एसएसएच प्रोटोकॉल ऑपरेशन एल्गोरिथम" विंदिकर , कर्रोप्लान और हब्बर समुदाय के अन्य सदस्यों की सिफारिशों के अनुसार बदल दिया गया था)

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

मैं SSH प्रोटोकॉल के संचालन में कुछ स्पष्टता लाने की कोशिश करूँगा, और साथ ही RSA एल्गोरिथ्म और उपयोगकर्ता प्राधिकरण कुंजी की भूमिका पर विचार करूँगा ...



SSH प्रोटोकॉल एल्गोरिदम को तीन स्तरों में विभाजित किया जा सकता है, जिनमें से प्रत्येक पिछले एक से ऊपर स्थित है: परिवहन (एक सुरक्षित चैनल खोलना), प्रमाणीकरण, कनेक्शन। चित्र अखंडता के लिए, मैं एक नेटवर्क कनेक्शन सेटअप स्तर भी जोड़ूंगा, हालांकि आधिकारिक तौर पर यह स्तर एसएसएच से नीचे है।

1. एक टीसीपी कनेक्शन स्थापित करें

मैं टीसीपी / आईपी स्टैक के सिद्धांत पर ध्यान केंद्रित नहीं करूंगा, क्योंकि इस विषय को रनेट में अच्छी तरह से प्रलेखित किया गया है। यदि आवश्यक हो, तो आप आसानी से जानकारी पा सकते हैं।

इस बिंदु पर, क्लाइंट सर्वर कॉन्फ़िगरेशन फ़ाइल / etc / ssh / sshd_config में पोर्ट विकल्प (डिफ़ॉल्ट: 22) में निर्दिष्ट टीसीपी पोर्ट पर सर्वर से कनेक्ट होता है।

2. एक सुरक्षित चैनल खोलना

२.१ पहचान विनिमय

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

2.2 एल्गोरिदम की पसंद: प्रमुख विनिमय, एन्क्रिप्शन, संपीड़न, आदि।

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

उपलब्ध क्लाइंट-साइड कुंजी विनिमय एल्गोरिदम की एक सूची (एक सत्र कुंजी प्राप्त करने के लिए उपयोग की जाती है) को कमांड के साथ देखा जा सकता है:

ssh -Q kex 

सिस्टम में उपलब्ध सममित एल्गोरिदम की सूची (चैनल एन्क्रिप्शन के लिए प्रयुक्त):

 ssh -Q cipher 

क्लाइंट पर प्राधिकरण के लिए प्रमुख प्रकारों की सूची:

 ssh -Q key-cert 

Onix74 टिप्पणी द्वारा अद्यतन:
प्रकाशन में उपयोग की जाने वाली सभी कमांड्स उबंटू 18.04 एलटीएस से ओपनएसएसएच संस्करण 7.6 के लिए प्रासंगिक हैं।

2.3 सत्र एन्क्रिप्शन कुंजी प्राप्त करना

एल्गोरिथ्म के संस्करण के आधार पर एक सत्र कुंजी प्राप्त करने की प्रक्रिया भिन्न हो सकती है, लेकिन सामान्य शब्दों में यह निम्नलिखित पर निर्भर करता है:

• सर्वर क्लाइंट (डीएसए, आरएसए, इत्यादि को क्लॉज 2.2 में निर्मित पार्टियों के बीच समझौते के अनुसार) अपनी कुंजी भेजता है।
• यदि क्लाइंट पहली बार इस सर्वर से जुड़ता है (जैसा कि क्लाइंट में /home/username/.ssh/ogn_hosts फ़ाइल में प्रविष्टि की कमी से संकेत मिलता है), तो उपयोगकर्ता से सर्वर कुंजी पर भरोसा करने के बारे में पूछा जाएगा। यदि इस सर्वर के साथ कनेक्शन पहले ही स्थापित हो चुका है, तो क्लाइंट भेजे गए कुंजी की तुलना /home/username/.ssh/ogn_hosts में दर्ज की गई कुंजी से करता है। यदि चाबियाँ मेल नहीं खाती हैं, तो उपयोगकर्ता को हैकिंग के संभावित प्रयास के बारे में एक चेतावनी मिलेगी। हालाँकि, आप इस चेक को छोड़ सकते हैं यदि आप StrictHostKeyChecking विकल्प के साथ ssh कहते हैं:
  

   ssh -o StrictHostKeyChecking=no username@servername 

  इसके अलावा, यदि उपयोगकर्ता को पुरानी सर्वर कुंजी को हटाने की आवश्यकता है (उदाहरण के लिए, जब एक निश्चित निश्चितता है कि कुंजी सर्वर पर बदल दी गई है), तो कमांड का उपयोग किया जाता है:
  

   ssh-keygen -R servername 

  
  
• डिफी-हेलमैन एल्गोरिथम के एक कार्यान्वयन (संस्करण को धारा 2.2 में परिभाषित किया गया है) का उपयोग करते हुए एक बार क्लाइंट ने सर्वर कुंजी में विश्वास का निर्धारण किया है, क्लाइंट और सर्वर एक सत्र कुंजी उत्पन्न करते हैं जिसका उपयोग सममित चैनल एन्क्रिप्शन के लिए किया जाएगा।
  

एक सत्र कुंजी चैनल के जीवन के लिए विशेष रूप से बनाई गई है और कनेक्शन बंद होने पर नष्ट हो जाती है।

3. ग्राहक प्रमाणीकरण

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

सामान्य शब्दों में, कुंजी प्रमाणीकरण निम्नानुसार होता है:

• क्लाइंट सर्वर को एक उपयोगकर्ता नाम (उपयोगकर्ता नाम) और उसकी सार्वजनिक कुंजी भेजता है।
• क्लाइंट द्वारा भेजी गई सार्वजनिक कुंजी के लिए सर्वर फ़ाइल /home/username/.ssh/authorized_keys की जाँच करता है। यदि सार्वजनिक कुंजी मिलती है, तो सर्वर एक यादृच्छिक संख्या उत्पन्न करता है और इसे ग्राहक की सार्वजनिक कुंजी के साथ एन्क्रिप्ट करता है, जिसके बाद परिणाम ग्राहक को भेजा जाता है।
• क्लाइंट अपनी निजी कुंजी के साथ संदेश को डिक्रिप्ट करता है और सर्वर को परिणाम भेजता है।
• सर्वर उस संख्या के साथ एक मिलान के लिए परिणाम की जांच करता है जिसे मूल रूप से ग्राहक की सार्वजनिक कुंजी के साथ एन्क्रिप्ट किया गया था, और यदि यह मेल खाता है, तो यह प्रमाणीकरण को सफल मानता है।

4. कनेक्शन स्तर

उपरोक्त सभी प्रक्रियाओं को करने के बाद, उपयोगकर्ता को सर्वर पर कमांड भेजने या फ़ाइलों को कॉपी करने का अवसर मिलता है।

इस स्तर पर, यह प्रदान किया जाता है: चैनलों का गुणन (एक चैनल में कई चैनलों को एक सर्वर से संचालित करने की क्षमता), सुरंग बनाना, आदि।

सिद्धांत से अभ्यास तक

खैर, अब, मुझे लगता है, पाठकों के पास एक पूरी तरह से तार्किक सवाल है: आपको एसएसएच प्रोटोकॉल के इन सभी विवरणों को जानने की आवश्यकता क्यों है, अगर रोजमर्रा के काम के लिए टर्मिनल सत्र (ssh-keygen), टर्मिनल सत्र (ssh) खोलने, फ़ाइल स्थानांतरण ( SCP)?

एक उत्तर के रूप में, हम मानक SSH पोर्ट को कुछ अन्य में बदलने के विषय को याद कर सकते हैं, जो लगातार होली पर होलीवर का कारण बनता है ...

अपने स्वयं के अभ्यास में, मुझे बाहरी नेटवर्क को देखने वाला एक भी सर्वर याद नहीं है जो पोर्ट 22 पर दैनिक टैप नहीं किया जाएगा। ऐसी स्थिति में जहां SSH आपके लिए एक मानक पोर्ट पर काम करता है (और किसी भी चीज़ से सुरक्षित नहीं है), भले ही चाबियाँ और कोई पासवर्ड अनुमान से प्रमाणीकरण डरावना हो, फिर बेईमान ग्राहकों से लगातार झूठ बोलने के अनुरोध के कारण, सर्वर अभी भी बहुत सारे बेकार काम करने के लिए मजबूर है: टीसीपी कनेक्शन स्थापित करें, एल्गोरिदम का चयन करें, सत्र कुंजी उत्पन्न करें, प्रमाणीकरण अनुरोध भेजें, लॉग फ़ाइल लिखें।

ऐसी स्थिति में जहां 22 वें पोर्ट पर कुछ भी नहीं है, या पोर्ट को iptables (या फ़ेल-ऑन जैसे फेल 2 एबन) का उपयोग करके सुरक्षित किया गया है, हमलावर टीसीपी कनेक्शन स्थापित करने के चरण में छोड़ देगा।

सबसे दिलचस्प वर्णित तालिका की तरह लग रहा है *

विन्यास	हैकिंग चांस	बाढ़ के नुकसान **
22 बंदरगाह पासवर्ड प्राधिकरण, बिना सुरक्षा के	उच्च	उच्च
22 बंदरगाह प्रमुख प्राधिकरण, बिना सुरक्षा के	औसत ***	उच्च
22 बंदरगाह प्रमुख प्राधिकरण, असफल प्राधिकरण प्रयासों के प्रतिबंध के आधार पर सुरक्षा	कम	मध्यम ****
गैर-मानक पोर्ट, पासवर्ड प्राधिकरण, बिना सुरक्षा के	उच्च	कम
गैर-मानक पोर्ट, प्रमुख प्राधिकरण, बिना सुरक्षा के	औसत ***	कम
गैर-मानक पोर्ट, प्रमुख प्राधिकरण, असफल प्राधिकरण प्रयासों के प्रतिबंध के आधार पर सुरक्षा	कम	कम

* - पैरामीटर मान (उच्च, मध्यम, निम्न) प्रकृति में सापेक्ष हैं और केवल संकेतक की तुलना करने के लिए सेवा करते हैं।
** - इसका अर्थ सर्वर के संसाधन खपत (प्रोसेसर, डिस्क, नेटवर्क चैनल, आदि) अनुरोधों के हिमस्खलन को संसाधित करने के लिए है जो आमतौर पर पोर्ट 22 पर जाते हैं।
*** - हैकिंग अगर आरएसए चाबियाँ प्राधिकरण के लिए उपयोग की जाती हैं तो बहुत मुश्किल है, लेकिन असीमित संख्या में प्राधिकरण प्रयास इसे संभव बनाता है।
**** - प्राधिकरण के प्रयासों की संख्या सीमित है, लेकिन सर्वर को अभी भी बड़ी संख्या में घुसपैठियों से उन्हें संसाधित करना है।

अतिरिक्त सामग्री

• SSH के सूत्र
• एसएसएच प्रोटोकॉल विनिर्देशों
• डिफी-हेलमैन एलगोरिदम
• आरएसए एल्गोरिदम
• कैसे SSH पोर्ट 22 पर दिखाई दिया
• .Ssh / ज्ञात_होस्ट फ़ाइल में क्या लिखा है
• उपयोगकर्ताओं को ssh मेमो