SSH का इतिहास: Telnet से OpenSSH तक का सफर

SSH का इतिहास कहाँ से शुरू होता है

SSH का इतिहास चोरी हुए पासवर्ड से शुरू होता है। 1995 से पहले, किसी रिमोट Unix मशीन में लॉग इन करने का मतलब telnet या rlogin का उपयोग करना था, और ये दोनों ही आपके पासवर्ड को नेटवर्क पर पठनीय टेक्स्ट (readable text) के रूप में भेजते थे। जो कोई भी नेटवर्क ट्रैफिक को देख सकता था, वह इसे पढ़ सकता था, और 1990 के दशक की शुरुआत तक लोग बड़े पैमाने पर ठीक यही कर रहे थे।

SSH इस समस्या का एक व्यक्ति द्वारा दिया गया समाधान था, जिसे 1995 में लिखा गया और मुफ्त में उपलब्ध कराया गया। तब से इस प्रोटोकॉल को एक बार फिर से बनाया गया है, और आज लगभग हर कोई जो प्रोग्राम चलाता है, वह एक फोर्क का फोर्क (fork of a fork) है। नीचे दी गई तारीखें महत्वपूर्ण हैं, क्योंकि हर कदम एक विशिष्ट विफलता (failure) के जवाब में उठाया गया था।

Telnet और rlogin वास्तव में क्या भेजते थे

Telnet को RFC 854 में परिभाषित किया गया है, जिसे मई 1983 में Jon Postel और Joyce Reynolds द्वारा प्रकाशित किया गया था। यह TCP पर चलने वाले टर्मिनल सत्र का वर्णन करता है, और इसमें किसी भी प्रकार का एन्क्रिप्शन नहीं होता है। आपके द्वारा टाइप किया गया प्रत्येक बाइट, जिसमें आपका पासवर्ड भी शामिल है, सादे बाइट्स के रूप में यात्रा करता है जिसे रास्ते में आने वाला कोई भी उपकरण पढ़ सकता है।

rlogin Berkeley Unix से आया था और इसे बाद में RFC 1282 (BSD Rlogin, B. Kantor, दिसंबर 1991) में लिखा गया था। इसने पठनीय पासवर्ड से भी बदतर एक चीज जोड़ी: होस्ट-आधारित विश्वास (host-based trust)। एक सर्वर को यह निर्देश दिया जा सकता था कि वह बिना किसी पासवर्ड के एक नामित होस्ट से लॉगिन स्वीकार करे। RFC में "A Cautionary Tale" (एक चेतावनी भरी कहानी) नामक एक खंड है जो कहता है कि "विश्वसनीय होस्ट से पासवर्ड प्रमाणीकरण को बायपास करना उन सभी सिस्टम को खोल देता है जो इस तरह कॉन्फ़िगर किए गए हैं, जब उनमें से केवल एक भी समझौता (compromise) हो जाता है।" यह यह भी नोट करता है कि विश्वास होस्टनामों पर आधारित है, इसलिए DNS (डोमेन नेम सिस्टम) के साथ समझौता या स्पूफ किया गया पता इसे विफल कर देता है।

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

1994 की सलाह जिसमें कोई समाधान नहीं था

3 फरवरी 1994 को CERT ने सलाह CA-94:01, "Ongoing Network Monitoring Attacks" प्रकाशित की। इसमें बताया गया कि घुसपैठियों ने इंटरनेट पर हजारों सिस्टमों की एक्सेस जानकारी चुरा ली थी। वे जिस टूल का उपयोग करते थे, वह नेटवर्क इंटरफेस को promiscuous mode में डाल देता था और हर नए telnet, rlogin और FTP सेशन की शुरुआत को रिकॉर्ड कर लेता था; यह वह हिस्सा है जिसमें यूजरनेम और पासवर्ड होता है।

CERT ने साइटों को सलाह दी कि वे नेटवर्क-एक्सेस वाले हर अकाउंट का पासवर्ड बदलें। जब आप इसे प्रोटोकॉल के संदर्भ में देखते हैं, तो समस्या स्पष्ट हो जाती है: नया पासवर्ड पहली बार इस्तेमाल किए जाने पर उसी वायर से clear text में गुजरता है। telnet या rlogin के भीतर कोई समाधान मौजूद नहीं था, क्योंकि इनमें से किसी भी प्रोटोकॉल में इसे लागू करने की कोई जगह नहीं थी।

Helsinki में sniffing attack के कारण SSH का निर्माण क्यों हुआ

1995 में Helsinki University of Technology के नेटवर्क पर एक password sniffing attack हुआ, जैसा कि CERT ने वर्णित किया था। वहां के एक शोधकर्ता Tatu Ylönen ने इसका एक विकल्प लिखा और जुलाई 1995 में इसे freeware के रूप में जारी किया। उन्होंने इसे Secure Shell नाम दिया।

दो डिज़ाइन निर्णयों ने इसे सफल बनाया। session को encrypt किया गया था, इसलिए नेटवर्क segment पर सुनने वाले किसी व्यक्ति को कोई उपयोगी जानकारी नहीं मिली। और server ने एक key के साथ अपनी पहचान साबित की, ताकि client यह बता सके कि वह सही मशीन से जुड़ा है या नहीं; यही वह खामी थी जिसे rlogin का hostname trust खुला छोड़ देता था।

यह इसलिए भी फैला क्योंकि इसके commands वही थे जो लोग पहले से टाइप करते थे। ssh ने rsh और rlogin की जगह ली, और scp ने rcp की जगह ली। स्विच करने में केवल आदत बदलनी पड़ी, workflow नहीं। 1995 के अंत तक इसके उपयोगकर्ताओं की संख्या पचास देशों में लगभग 20,000 तक पहुँच गई थी। उस दिसंबर में, Ylönen ने सॉफ्टवेयर को विकसित करने और बेचने के लिए SSH Communications Security की स्थापना की।

एक मुफ्त release से एक commercial product तक

जैसे-जैसे SSH एक व्यवसाय बना, source code का licence बदल गया। बाद के releases में ऐसी शर्तें शामिल थीं जिन्होंने दूसरों के लिए code के उपयोग को सीमित कर दिया, और ssh 1.2.12 अंतिम ऐसा release था जिसे कोई भी स्वतंत्र रूप से reuse कर सकता था। इसमें कुछ भी अनुचित नहीं है। इसका सीधा सा अर्थ यह था कि SSH का वह version जिस पर बाकी दुनिया काम कर सकती थी, वह स्थिर हो गया, जबकि विकास ऐसी जगह जारी रहा जहाँ बाकी दुनिया उसका अनुसरण नहीं कर सकती थी। Licences यह तय करते हैं कि कौन सा code जीवित रहेगा, यह एक ऐसा pattern है जिसके बारे में how open source licensing shaped modern infrastructure में पढ़ना सार्थक है।

1999 में OpenBSD ने OpenSSH को क्यों fork किया

1999 की शुरुआत में Björn Grönvall उस अंतिम free release पर वापस गए और उसमें मौजूद bugs को ठीक करना शुरू किया। उनके version का नाम OSSH था, और यह केवल SSH 1.3 protocol पर काम करता था।

OpenBSD project ने OSSH को लिया और उसे फिर से तैयार किया। project के अपने विवरण के अनुसार, Theo de Raadt, Niels Provos, Markus Friedl, Bob Beck, Aaron Campbell और Dug Song ने code की सफाई, ऑडिटिंग और उसे विस्तार देने का काम किया। इसका परिणाम OpenSSH 1.2.2 था, जिसे 1 दिसंबर 1999 को OpenBSD 2.6 के साथ release किया गया।

एक छोटे operating system project द्वारा किए गए fork को लगभग हर machine पर जगह क्यों मिली? क्योंकि OpenBSD को इसकी आवश्यकता थी। OpenBSD एक audited base system प्रदान करता है जिसे default configuration में सुरक्षित रहने के लिए बनाया गया है, इसलिए encrypted remote login को उस base system का हिस्सा होना था, जिसके साथ कोई प्रतिबंध न हो। बिना किसी प्रतिबंध वाले license के तहत audited code ही वह चीज है जिसकी हर दूसरे operating system vendor को तलाश थी। Damien Miller, Philip Hands और अन्य लोगों ने लगभग तुरंत ही एक portable branch शुरू की, जहाँ से 10.5p1 जैसे version में मौजूद p आता है। OpenBSD clean version को विकसित करता है, और portable branch बाकी सभी चीजों के लिए आवश्यक glue जोड़ती है। Unix जिस तरह से उन systems में विभाजित हुआ जिन्हें हम आज चलाते हैं यही कारण है कि उस glue की आवश्यकता क्यों है।

दूसरे protocol version के लिए support इसके बाद आया। OpenSSH 2.0 को 15 जून 2000 को OpenBSD 2.7 के साथ release किया गया।

SSH-2 एक नया प्रोटोकॉल क्यों है, न कि केवल एक वर्ज़न अपडेट

SSH-1 ने एन्क्रिप्टेड स्ट्रीम की अखंडता (integrity) की सुरक्षा के लिए CRC-32 का उपयोग किया था। यह एक ऐसा चेकसम था जिसे ट्रांसमिशन त्रुटियों को पकड़ने के लिए बनाया गया था, न कि किसी हमलावर का सामना करने के लिए। 1998 में CORE SDI के Ariel Futoransky और Emiliano Kargieman ने दिखाया कि इसकी कीमत क्या चुकानी पड़ती है। CBC या CFB सिफर मोड और CRC-32 चेक के साथ, एक हमलावर जिसे प्लेनटेक्स्ट के केवल 16 बाइट्स की जानकारी हो, वह अपनी चुनी हुई सिफरटेक्स्ट डाल सकता है जिसे रिसीवर असली मान लेता है। इसका अर्थ है सर्वर पर कमांड्स को रन करना।

यह खामी प्रोटोकॉल के भीतर थी, इसलिए संगतता (compatibility) तोड़े बिना इसे ठीक नहीं किया जा सकता था। सॉफ्टवेयर के वर्ज़न्स में इसके बजाय एक डिटेक्टर शामिल किया गया, जो deattack.c नामक फाइल में मौजूद कोड था। यह कोड हमले को होते ही पहचानने का प्रयास करता था। फरवरी 2001 में पता चला कि डिटेक्टर में खुद एक integer overflow मौजूद था, जिसे CVE-2001-0144 कहा गया। इसने उन सर्वर्स और क्लाइंट्स के खिलाफ रिमोट कोड एक्जीक्यूशन की सुविधा दी, जिन्होंने पैच लागू किया था। एक ऐसा डिज़ाइन जिसे सुधारा नहीं जा सकता, वह पैच इकट्ठा करता रहता है, और पैच अपने साथ नए बग्स लाते हैं।

SSH-2 को IETF के secsh नामक वर्किंग ग्रुप में तैयार किया गया और जनवरी 2006 में RFCs के रूप में प्रकाशित किया गया: RFC 4251 में आर्किटेक्चर, RFC 4253 में ट्रांसपोर्ट लेयर, RFC 4252 में यूजर ऑथेंटिकेशन और RFC 4254 में कनेक्शन लेयर। लेयर्स में विभाजन सबसे महत्वपूर्ण हिस्सा है, क्योंकि प्रत्येक लेयर को स्वतंत्र रूप से बदला जा सकता है। इस इतिहास का बाकी अधिकांश हिस्सा इसी बदलाव के बारे में है।

दो बदलाव विशेष रूप से महत्वपूर्ण हैं। अखंडता (integrity) को CRC-32 से हटाकर एक HMAC (hash-based message authentication code) पर ले जाया गया, जिसे एक साझा सीक्रेट (shared secret) के साथ की (key) किया गया। इसलिए, जो हमलावर MAC की गणना नहीं कर सकता, वह पैकेट को फर्जी नहीं बना सकता। और की एग्रीमेंट (key agreement) को Diffie-Hellman पर स्थानांतरित कर दिया गया। SSH-1 में क्लाइंट सेशन की को चुनता था और उसे सर्वर की RSA कीज़ के तहत एन्क्रिप्ट करके भेजता था। इसलिए, जो कोई भी बाद में उन प्राइवेट कीज़ को प्राप्त कर लेता, वह रिकॉर्ड किए गए सेशन को डिक्रिप्ट कर सकता था। Diffie-Hellman प्रत्येक सेशन के लिए एक नया सीक्रेट बनाता है जिसे कभी ट्रांसमिट नहीं किया जाता। इसलिए, ट्रैफिक को अभी रिकॉर्ड करने और बाद में होस्ट की चुराने से कुछ हासिल नहीं होता। इस विशेषता को फॉरवर्ड सीक्रेसी (forward secrecy) कहा जाता है।

SSH-2 की SSH-1 के साथ कोई वायर कम्पैटिबिलिटी (wire compatibility) नहीं है। यही कारण है कि वर्ज़न नंबर को डेसिमल के बजाय पूरी तरह बदला गया।

SSH-1 को सुधारे जाने के बजाय हटाया क्यों गया

इसे हटाने की प्रक्रिया तीन OpenSSH releases में पूरी हुई। 11 अगस्त 2015 को आए version 7.0 में, compile time पर protocol 1 को डिफ़ॉल्ट रूप से disable कर दिया गया। 19 दिसंबर 2016 को आए version 7.4 में, इसके लिए server support हटा दिया गया। 3 अक्टूबर 2017 को आए version 7.6 में, client side को भी हटा दिया गया, साथ ही इसके configuration options और documentation को भी हटा दिया गया।

पुराने उपकरणों के लिए इसे एक विकल्प के रूप में बनाए रखना अधिक सुविधाजनक होता, लेकिन CRC-32 detector यह स्पष्ट करता है कि इस विकल्प को क्यों अस्वीकार किया गया। यह overflow केवल इसलिए पहुँच योग्य था क्योंकि protocol 1 का कोड compile किया गया था, और यह उस path में मौजूद था जिसे अधिकांश administrators अपने सिस्टम पर निष्क्रिय मानते थे। जो कोड ships होता है, उस तक पहुँचा जा सकता है। जो कोड हटा दिया गया है, उस तक नहीं पहुँचा जा सकता।

आपका पहला SSH कनेक्शन होस्ट की (host key) के बारे में चेतावनी क्यों देता है

एन्क्रिप्शन आपको यह बताता है कि ट्रैफ़िक निजी है। यह यह नहीं बताता कि दूसरे छोर पर कौन है। यदि कोई हमलावर रास्ते में बैठा है और आपके सर्वर की जगह जवाब देता है, तो आपको हमलावर के साथ एक पूरी तरह से एन्क्रिप्टेड सत्र प्राप्त होता है, जिसे machine-in-the-middle हमला कहते हैं। SSH इसका जवाब एक होस्ट की (host key) के साथ देता है: सर्वर यह साबित करता है कि उसके पास की-पेयर (key pair) का निजी हिस्सा है, और क्लाइंट उस की (key) की तुलना पिछली बार रिकॉर्ड की गई जानकारी से करता है। यदि आप कनेक्शन की कार्यप्रणाली को समझना चाहते हैं, तो देखें SSH कनेक्शन खोलने पर क्या होता है।

पहले कनेक्शन पर कोई पिछला रिकॉर्ड नहीं होता है, इसलिए क्लाइंट के पास तुलना करने के लिए कुछ नहीं होता है और उसे आपसे पूछना पड़ता है:

The authenticity of host 'vps.example.com (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:BQ0Qs2jVXhH2lPZ2rM0aQ0mQ8f9pQ0m3nH0oQ1bYqkE.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

हाँ (yes) कहने पर वह की (key) ~/.ssh/known_hosts में स्टोर हो जाती है। बाद का हर कनेक्शन स्टोर की गई वैल्यू से तुलना करता है, और मेल न खाने पर प्रोग्राम सबसे गंभीर संदेश देता है:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

उस पहले प्रॉम्प्ट का ईमानदार अर्थ यह है कि प्रोटोकॉल अपने एक कमजोर क्षण को स्वीकार कर रहा है। 'Trust on first use' का मतलब है कि पहला कनेक्शन केवल उतने ही सुरक्षित नेटवर्क पर सुरक्षित है जिस पर आपने इसे बनाया है। आप इस कमी को दूर कर सकते हैं। कनेक्ट करने से पहले अपने प्रदाता के कंसोल या सर्वर के बिल्ड लॉग से फिंगरप्रिंट पढ़ें। इसे DNS में SSHFP रिकॉर्ड (RFC 4255) के रूप में प्रकाशित करें, जो केवल तभी उपयोगी है जब आपके पास DNSSEC हो। या होस्ट की (host keys) को अपने स्वयं के सर्टिफिकेट अथॉरिटी (CA) के साथ साइन करें, ताकि क्लाइंट्स CA पर भरोसा करें, न कि प्रत्येक व्यक्तिगत की (key) पर। व्यवहार में अधिकांश लोग बिना जांचे प्रॉम्प्ट स्वीकार कर लेते हैं, जिसके बारे में ईमानदार रहना उचित है।

Public keys ने passwords की जगह कैसे ली

Public key authentication शुरुआती SSH releases से ही मौजूद थी, लेकिन इसे सामान्य आदत बनने में वर्षों लग गए। यह mechanism asymmetric है: client एक challenge को sign करके यह साबित करता है कि उसके पास private key है, और private key कभी भी client से बाहर नहीं जाती। Password इसके विपरीत काम करता है। भले ही SSH इसे encrypted channel के अंदर ले जाता है, लेकिन server को वास्तविक secret प्राप्त हो जाता है। इसलिए, यदि कोई server breach हो जाए या hostile हो, तो उसके पास ऐसी जानकारी आ जाती है जिसे वह कहीं और आपके खिलाफ इस्तेमाल कर सकता है।

दूसरा कारण गणितीय है। जिस भी server का port 22 public address पर open होता है, उसे चौबीसों घंटे automated login attempts का सामना करना पड़ता है, और password एक ऐसा string है जिसका अनुमान लगाया जा सकता है। एक key का व्यावहारिक रूप से अनुमान लगाना संभव नहीं है। PasswordAuthentication no को set करने से इस तरह के सभी हमलों का अंत हो जाता है, यही कारण है कि यह हर hardening checklist में शामिल होता है। Keys को generate और rotate करने की जानकारी SSH key management basics में दी गई है, और server-side settings के लिए hardening SSH on a VPS देखें।

SSH algorithm list में लगातार बदलाव क्यों होते हैं

एक layered protocol नए protocol की आवश्यकता के बिना algorithms को retire करने की अनुमति देता है। OpenSSH ने इस स्वतंत्रता का लगातार उपयोग किया है, और release dates इसकी गति को दर्शाती हैं।

Ed25519 को 30 January 2014 को OpenSSH 6.5 में पेश किया गया था, जिसके साथ chacha20-poly1305 cipher और bcrypt द्वारा सुरक्षित private key format भी शामिल थे। Ed25519 signatures अपने per-signature nonce को deterministically derive करते हैं, इसलिए signing के समय एक कमजोर random number generator private key को leak नहीं कर सकता। वास्तविक घटनाओं में DSA और ECDSA private keys को इसी तरह से recover किया गया है।

DSA के साथ इसके विपरीत हुआ। OpenSSH 7.0 ने 2015 में run time पर ssh-dss host और user keys को disable कर दिया, क्योंकि यह algorithm 160-bit private key और SHA-1 तक सीमित है। 1 July 2024 को आए Version 9.8 ने compile time पर DSA को disable कर दिया। 9 April 2025 को आए Version 10.0 ने इसे हटा दिया, जैसा कि project के शब्दों में कहा गया है, "2015 में शुरू हुई deprecation प्रक्रिया को पूरा किया गया"। disable होने से लेकर delete होने तक दस साल लगे।

RSA गायब नहीं हुआ, लेकिन इसका पुराना signature format जरूर हट गया। 26 September 2021 को आए OpenSSH 8.8 ने default रूप से SHA-1 के साथ बनाए गए RSA signatures को स्वीकार करना बंद कर दिया। release notes में इसका कारण स्पष्ट रूप से बताया गया है: SHA-1 cryptographically broken है, और chosen-prefix collisions को 50,000 USD से कम में प्राप्त किया जा सकता था। यदि आप किसी पुराने server से connect करते समय कभी sign_and_send_pubkey: no mutual signature supported से मिले हैं, तो वह इसी बदलाव के कारण है। आपकी key ठीक है। जिस signature algorithm की मांग दूसरी तरफ से की गई है, वह सुरक्षित नहीं है।

यही प्रक्रिया अब key exchange के लिए चल रही है, इस बार खतरे से पहले। आज capture किए गए traffic को store किया जा सकता है और वर्षों बाद किसी ऐसे व्यक्ति द्वारा decrypt किया जा सकता है जिसके पास सक्षम quantum computer हो, इसलिए ऐसी मशीन के अस्तित्व में आने से पहले key agreement को बदलना आवश्यक था। 8 April 2022 को आए OpenSSH 9.0 ने hybrid key exchange को default बना दिया: sntrup761x25519-sha512@openssh.com एक post-quantum algorithm को X25519 exchange के साथ pair करता है, ताकि यदि नया algorithm विफल भी हो जाए, तो परिणाम classical भाग से कमजोर न हो। 19 September 2024 को आए OpenSSH 9.9 ने mlkem768x25519-sha256 को जोड़ा, जो ML-KEM (module lattice key encapsulation mechanism) पर आधारित है, जिसे 2024 में NIST द्वारा standardize किया गया था। OpenSSH 10.0 ने इसे key agreement के लिए default बना दिया, और project का post-quantum page इसके पीछे के तर्क को समझाता है। 6 October 2025 को आए OpenSSH 10.1 ने warning देना शुरू किया जब दूसरा छोर इसे करने में सक्षम नहीं होता:

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded.

यह warning default रूप से चालू रहती है और इसे ssh_config में WarnWeakCrypto option द्वारा नियंत्रित किया जाता है। व्यवहार में इसका क्या अर्थ है, और जिस server पर यह trigger होता है उसके बारे में क्या करना है, यह post-quantum SSH key exchange defaults में बताया गया है।

आपके सामने मौजूद सर्वर के लिए इस इतिहास का क्या अर्थ है

आप जो command टाइप करते हैं, वह 1995 के बाद से शायद ही बदली है। इसके नीचे की लगभग हर चीज़ को बदल दिया गया है: integrity check, key exchange, signature algorithms, और स्वयं code base। यह केवल इसलिए संभव हुआ क्योंकि प्रत्येक प्रतिस्थापन (replacement) एक सोची-समझी removal के साथ समाप्त हुआ, और प्रत्येक removal ने किसी न किसी के लिए कुछ न कुछ तोड़ा।

इसलिए आपकी SSH security मुख्य रूप से आपके version द्वारा तय होती है। defaults में वे निर्णय शामिल होते हैं कि कौन से algorithms पेश किए जाएंगे, किनसे इनकार किया जाएगा और आपको कौन सी चेतावनियाँ दिखाई देंगी। एक पुराना सर्वर वही सब पेश करता रहता है जो उसके release के समय अनुमत था, और वह एक पुराने client से जुड़ने के लिए समझौता (negotiate) करता रहेगा। अगस्त 2026 तक, वर्तमान release OpenSSH 10.5 है, जिसे 11 अगस्त 2026 को प्रकाशित किया गया था। उस version और ऐसी मशीन पर मौजूद version के बीच का अंतर, जिसे तीन वर्षों से किसी ने नहीं छुआ है, समस्या का वास्तविक आकार है। इसकी जाँच करना नए VPS पर शुरुआती दस मिनट का हिस्सा है।

FAQ

SSH किसने बनाया और क्यों?

Helsinki University of Technology के एक शोधकर्ता Tatu Ylönen ने 1995 में विश्वविद्यालय के नेटवर्क पर हुए एक password sniffing हमले के बाद SSH लिखा। उस समय के remote login tools, जैसे telnet और rlogin, passwords को नेटवर्क पर readable text के रूप में भेजते थे। इसलिए, shared segment की निगरानी करने वाला कोई भी व्यक्ति गुजरते हुए credentials को collect कर सकता था। उन्होंने जुलाई 1995 में इस प्रोग्राम को freeware के रूप में release किया। उस साल के अंत तक पचास देशों में इसके लगभग 20,000 users थे, और दिसंबर 1995 में उन्होंने SSH Communications Security की स्थापना की।

SSH-1 और SSH-2 में क्या अंतर है?

ये अलग-अलग protocols हैं और इनमें wire compatibility नहीं है। SSH-1 एक एकल monolithic protocol था जो integrity के लिए CRC-32 का उपयोग करता था और इसमें client, server की RSA keys के तहत encrypted session key भेजता था। SSH-2 काम को transport layer, authentication layer और connection layer (RFCs 4251 से 4254, जनवरी 2006) में विभाजित करता है। यह integrity के लिए HMAC का उपयोग करता है और Diffie-Hellman के साथ session keys derive करता है, ताकि बाद में host key चोरी होने पर भी record किया गया traffic private रहे। SSH-1 को चरणों में OpenSSH से हटा दिया गया, जो अक्टूबर 2017 में version 7.6 के साथ समाप्त हुआ।

OpenSSH ने मूल SSH implementation की जगह क्यों ली?

मूल SSH का विकास एक restrictive licence वाले commercial product में बदल गया, और अंतिम freely reusable release ssh 1.2.12 था। 1999 की शुरुआत में Björn Grönvall ने उस release को OSSH के रूप में पुनर्जीवित किया, और OpenBSD टीम ने OSSH को fork करके OpenSSH बनाया, जिसे 1 दिसंबर 1999 को OpenBSD 2.6 के साथ ship किया गया। OpenBSD को अपने base system के लिए unrestricted licence के तहत audited code की आवश्यकता थी, और इन्हीं दो गुणों के कारण अन्य सभी operating systems portable branch के माध्यम से उसी implementation को ship कर पाते हैं।

पहली बार connect करते समय SSH host key के बारे में क्यों पूछता है?

क्योंकि client ने उस server को पहले कभी नहीं देखा है और उसके पास तुलना करने के लिए कोई key नहीं है। केवल encryption एक ईमानदार server को रास्ते में बैठे किसी machine से अलग नहीं कर सकता, इसलिए SSH servers की पहचान key से करता है और जो देखता है उसे ~/.ssh/known_hosts में record करता है। पहला connection वह क्षण है जब जाँचने के लिए कोई stored value नहीं होती, इसीलिए client आपसे पूछता है। fingerprint की तुलना provider console या server से प्राप्त fingerprint से करें, और किसी भी बाद के REMOTE HOST IDENTIFICATION HAS CHANGED संदेश को तब तक एक वास्तविक घटना मानें जब तक आप उसका कारण स्पष्ट न कर लें।

upgrade के बाद पुराने SSH keys काम करना क्यों बंद कर देते हैं?

क्योंकि OpenSSH एक निर्धारित schedule पर algorithms को retire करता है। DSA (ssh-dss) keys को 2015 में OpenSSH 7.0 में default रूप से disable कर दिया गया था और 9 अप्रैल 2025 को OpenSSH 10.0 में पूरी तरह से हटा दिया गया। RSA keys अभी भी काम करती हैं, लेकिन SHA-1 के साथ बनाए गए signatures को सितंबर 2021 में OpenSSH 8.8 में default रूप से disable कर दिया गया था, जो किसी पुराने server तक पहुँचने पर sign_and_send_pubkey: no mutual signature supported के रूप में दिखाई देता है। एक Ed25519 key, जो जनवरी 2014 में OpenSSH 6.5 के बाद से उपलब्ध है, इन दोनों समस्याओं से बचाती है।