SSH in hindi (SECURE SHELL in hindi):-
Secure Shell (SSH) सुरक्षित Network communication के लिए एक प्रोटोकॉल है जिसे लागू करने के लिए सरल और सस्ती होने के लिए डिज़ाइन किया गया है। early version, SSH 1 telnet और अन्य remote logon plans को बदलने के लिए एक सुरक्षित रिमोट लॉगऑन सुविधा प्रदान करने पर concentrate था जो कोई सुरक्षा प्रदान नहीं करता था। SSH अधिक सामान्य क्लाइंट/सर्वर क्षमता भी प्रदान करता है और file transfer और ई-मेल जैसे नेटवर्क कार्यों के लिए इसका उपयोग किया जा सकता है। एक नया version, SSH2, मूल योजना में कई सुरक्षा खामियों को ठीक करता है। SSH2 को IETF RFCs 4250 से 4256 में proposed standard के रूप में documented किया गया है।
अधिकांश ऑपरेटिंग सिस्टम के लिए SSH क्लाइंट और सर्वर application wide से उपलब्ध हैं। यह रिमोट लॉगिन और X tunneling के लिए पसंद का तरीका बन गया है और तेजी से embedded systems के बाहर encryption technology के लिए सबसे wide applications में से एक बन रहा है।
SSH को तीन प्रोटोकॉल के रूप में व्यवस्थित किया जाता है जो आमतौर पर TCP पर चलते हैं।
1. Transport Layer Protocol
2. User Authentication Protocol
3. Connection Protocol
1. Transport Layer Protocol:-
आगे की privacy के साथ server authentication, डेटा privacy और डेटा integrity प्रदान करता है (यानी, यदि एक session के दौरान एक keys से समझौता किया जाता है, तो knowledge past sessions की सुरक्षा को प्रभावित नहीं करता है)। transport layer alternative से compression प्रदान कर सकती है।
2. User Authentication Protocol:-
उपयोगकर्ता को सर्वर पर certified करता है।
3. Connection Protocol:-
single, built-in SSH कनेक्शन पर Multiple logical communication channels को मल्टीप्लेक्स करता है।
Transport Layer Protocol:-
HOST KEYS server authentication सार्वजनिक/निजी keys युग्म रखने वाले सर्वर के आधार पर ट्रांसपोर्ट लेयर पर होता है। एक सर्वर में कई अलग-अलग asymmetric encryption algorithms का उपयोग करके कई host keys हो सकती हैं। एकाधिक host एक ही host key sharing कर सकते हैं। किसी भी स्थिति में, होस्ट की पहचान को authentication करने के लिए key exchange के दौरान server host key का उपयोग किया जाता है। इसके लिए संभव होने के लिए, क्लाइंट को सर्वर की public host key का प्राथमिक ज्ञान होना चाहिए। RFC 4251 दो Alternate Trust Model करता है जिनका उपयोग किया जा सकता है:
1. क्लाइंट के पास एक स्थानीय डेटाबेस होता है जो प्रत्येक होस्ट नाम (उपयोगकर्ता द्वारा टाइप किया गया) को संबंधित public host key से जोड़ता है। इस method के लिए किसी centrally administered infrastructure और किसी तीसरे पक्ष के harmony की आवश्यकता नहीं है। नकारात्मक पक्ष यह है कि name-to-key associations का डेटाबेस बनाए रखने के लिए हो सकता है।
2. host name-to-key association एक trusted certification authority(CA) द्वारा certified है। क्लाइंट केवल CA root key जानता है और CA द्वारा certified सभी host keys की validity को verified कर सकता है। यह विकल्प रखरखाव की समस्या को आसान बनाता है, आदर्श रूप से, क्लाइंट पर केवल एक CA key को सुरक्षित रूप से store करने की आवश्यकता होती है। दूसरी ओर, authorization possible होने से पहले प्रत्येक host keys को central authority द्वारा certified किया जाना चाहिए।
टिप्पणियाँ
एक टिप्पणी भेजें