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

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

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

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

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

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

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

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

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

3 February 1994 को CERT ने advisory 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 के नेटवर्क पर एक पासवर्ड sniffing attack हुआ, जैसा कि CERT ने पहले बताया था। वहाँ के एक शोधकर्ता Tatu Ylönen ने इसका एक विकल्प लिखा और जुलाई 1995 में इसे freeware के रूप में जारी किया। उन्होंने इसे Secure Shell नाम दिया।

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

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

फ्री रिलीज से कमर्शियल प्रोडक्ट तक

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

OpenBSD ने 1999 में 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 की सफाई, auditing और उसे विस्तारित करने का काम किया। इसका परिणाम 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 के तहत। बिना किसी प्रतिबंध वाले 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 के लिए समर्थन इसके बाद आया। OpenSSH 2.0 को 15 जून 2000 को OpenBSD 2.7 के साथ release किया गया।

SSH-2 एक नया protocol क्यों है, न कि केवल एक version bump

SSH-1 ने encrypted stream की integrity को CRC-32 के साथ सुरक्षित किया था। यह एक ऐसा checksum था जिसे transmission errors को पकड़ने के लिए बनाया गया था, न कि हमलावर का सामना करने के लिए। 1998 में CORE SDI के Ariel Futoransky और Emiliano Kargieman ने दिखाया कि इसकी कीमत क्या है। CBC या CFB cipher modes और CRC-32 check के साथ, एक हमलावर जिसे plaintext के केवल 16 bytes की जानकारी हो, वह अपनी पसंद का ciphertext डाल सकता है जिसे receiver असली मान लेता है। इसका मतलब है सर्वर पर commands चलाना।

यह खामी protocol के भीतर थी, इसलिए compatibility तोड़े बिना इसे ठीक नहीं किया जा सकता था। implementations ने इसके बजाय एक detector भेजा, जो deattack.c नामक file में मौजूद code था। यह हमला होने पर उसे पहचानने की कोशिश करता था। फरवरी 2001 में पता चला कि detector में खुद एक integer overflow था, जिसे CVE-2001-0144 कहा गया। इसने उन servers और clients पर remote code execution की अनुमति दे दी जिन्होंने patch लगाया था। एक ऐसा design जिसे सुधारा नहीं जा सकता, वह patches जमा करता है, और patches अपने साथ नए bugs लाते हैं।

SSH-2 पर IETF के secsh नामक working group में काम किया गया और जनवरी 2006 में इसे RFCs के रूप में प्रकाशित किया गया: RFC 4251 में architecture, RFC 4253 में transport layer, RFC 4252 में user authentication, और RFC 4254 में connection layer। layers में विभाजन सबसे महत्वपूर्ण हिस्सा है, क्योंकि प्रत्येक layer को स्वतंत्र रूप से बदला जा सकता है। इस इतिहास का बाकी अधिकांश हिस्सा इसी बदलाव के बारे में है।

दो बदलाव विशेष रूप से उल्लेखनीय हैं। Integrity को CRC-32 से हटाकर एक HMAC (hash-based message authentication code) पर ले जाया गया, जिसे एक shared secret के साथ key किया जाता है। इसलिए, जो हमलावर MAC की गणना नहीं कर सकता, वह packet को forge नहीं कर सकता। और key agreement को Diffie-Hellman पर ले जाया गया। SSH-1 में, client session key चुनता था और उसे server की RSA keys के तहत encrypt करके भेजता था। इसलिए, जो कोई भी बाद में उन private keys को प्राप्त कर लेता, वह record किए गए session को decrypt कर सकता था। Diffie-Hellman प्रत्येक session के लिए एक नया secret बनाता है जिसे कभी transmit नहीं किया जाता। इसलिए, traffic को अभी record करने और बाद में host key चुराने से कुछ हासिल नहीं होता। इस गुण को forward secrecy कहा जाता है।

SSH-2 की wire compatibility SSH-1 के साथ बिल्कुल नहीं है। इसीलिए version number को decimal के बजाय बदला गया।

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 डिटेक्टर यह स्पष्ट करता है कि उस विकल्प को क्यों अस्वीकार कर दिया गया। overflow केवल इसलिए पहुँच योग्य था क्योंकि protocol 1 का कोड compile किया गया था, और यह उस path में मौजूद था जिसे अधिकांश administrators अपने सिस्टम पर निष्क्रिय मानते थे। जो कोड ships होता है, उस तक पहुँचा जा सकता है। जो कोड डिलीट कर दिया गया है, उस तक नहीं पहुँचा जा सकता।

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

Encryption आपको यह बताता है कि traffic private है। यह यह नहीं बताता कि दूसरी तरफ कौन है। यदि कोई हमलावर रास्ते में बैठा है और आपके सर्वर की जगह जवाब देता है, तो आपको हमलावर के साथ एक पूरी तरह से encrypted session मिलता है, जिसे machine-in-the-middle attack कहा जाता है। SSH इसका जवाब एक host key के साथ देता है: सर्वर यह साबित करता है कि उसके पास key pair का private हिस्सा है, और client उस key की तुलना पिछली बार record किए गए डेटा से करता है। यदि आप connection की कार्यप्रणाली को समझना चाहते हैं, तो SSH connection खोलने पर क्या होता है देखें।

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

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 में store हो जाती है। बाद का हर connection store की गई value से तुलना करता है, और mismatch होने पर program सबसे गंभीर चेतावनी देता है:

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

उस पहले prompt का ईमानदार अर्थ यह है कि protocol अपने एक कमजोर क्षण को स्वीकार कर रहा है। Trust on first use का मतलब है कि पहला connection उतना ही सुरक्षित है जितना कि वह network जिस पर आपने इसे बनाया है। आप इस कमी को दूर कर सकते हैं। connect करने से पहले अपने provider के console या सर्वर के build log से fingerprint पढ़ें। इसे DNS में SSHFP record (RFC 4255) के रूप में publish करें, जो केवल तभी उपयोगी है जब आपके पास DNSSEC हो। या फिर host keys को अपनी certificate authority (CA) से sign करें, ताकि clients CA पर भरोसा करें, न कि हर एक key पर। व्यवहार में, अधिकांश लोग बिना जांचे ही prompt को स्वीकार कर लेते हैं, जिसके बारे में ईमानदार रहना उचित है।

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

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

दूसरा कारण गणितीय है। सार्वजनिक address पर port 22 खुला रखने वाले किसी भी server को चौबीसों घंटे automated login attempts मिलते रहते हैं, और password का अनुमान लगाया जा सकता है। व्यावहारिक अर्थ में key का अनुमान नहीं लगाया जा सकता। PasswordAuthentication no सेट करने से हमलों की यह पूरी श्रेणी समाप्त हो जाती है, इसलिए यह हर hardening checklist में शामिल होता है। इससे वह fallback भी हट जाता है, जो key में समस्या आने पर आपको बचा सकता था। इसलिए locked out होने से पहले Permission denied (publickey) रिपोर्ट करने वाली अलग-अलग समस्याओं को पहचानना सीखें। Password के बिना काम करने का अर्थ keys जमा करते जाना भी है। एक agent में एक दर्जन keys होने पर वह हर key को क्रम से आज़माता है, जब तक server अपनी attempt limit तक नहीं पहुँच जाता और connection बंद नहीं कर देता। इसी कारण सही key loaded होने पर भी login Too many authentication failures के साथ विफल हो सकता है: इस समस्या का कारण यहाँ देखें। Keys generate और rotate करने की जानकारी SSH key management की मूल बातें में है। Server-side settings की जानकारी VPS पर SSH को harden करना में है।

SSH एल्गोरिदम सूची में लगातार बदलाव क्यों होते हैं

एक लेयर्ड प्रोटोकॉल नए प्रोटोकॉल की आवश्यकता के बिना पुराने एल्गोरिदम को रिटायर करने की सुविधा देता है। OpenSSH ने इस स्वतंत्रता का लगातार उपयोग किया है, और इसके release dates इसकी गति को दर्शाते हैं।

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

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

RSA गायब नहीं हुआ, लेकिन इसका पुराना signature format जरूर हट गया। 26 September 2021 को आए OpenSSH 8.8 ने डिफ़ॉल्ट रूप से SHA-1 के साथ बने RSA signatures को स्वीकार करना बंद कर दिया। release notes में इसका कारण स्पष्ट है: SHA-1 cryptographically broken है, और chosen-prefix collisions को 50,000 USD से कम में प्राप्त किया जा सकता था। यदि आप किसी पुराने सर्वर से 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 को डिफ़ॉल्ट बना दिया: sntrup761x25519-sha512@openssh.com एक post-quantum एल्गोरिदम को X25519 exchange के साथ जोड़ता है, ताकि यदि नया एल्गोरिदम उम्मीदों पर खरा न उतरे, तो परिणाम classical भाग से कमजोर न हो। 19 September 2024 को आए OpenSSH 9.9 ने mlkem768x25519-sha256 को जोड़ा, जो ML-KEM (module lattice key encapsulation mechanism) पर आधारित है, जिसे 2024 में NIST द्वारा मानकीकृत किया गया था। OpenSSH 10.0 ने इसे key agreement के लिए डिफ़ॉल्ट बना दिया, और प्रोजेक्ट का post-quantum पेज इसके पीछे का तर्क स्पष्ट करता है। 6 October 2025 को आए OpenSSH 10.1 ने चेतावनी देना शुरू किया जब दूसरी तरफ का सिस्टम इसे सपोर्ट नहीं करता:

** 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.

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

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

आप जो कमांड टाइप करते हैं, वह 1995 के बाद से शायद ही बदली है। इसके नीचे की लगभग हर चीज को बदल दिया गया है: इंटीग्रिटी चेक, की एक्सचेंज, सिग्नेचर एल्गोरिदम और स्वयं कोड बेस। यह केवल इसलिए संभव हुआ क्योंकि प्रत्येक प्रतिस्थापन (replacement) एक जानबूझकर किए गए निष्कासन (removal) पर समाप्त हुआ, और प्रत्येक निष्कासन ने किसी न किसी के लिए कुछ न कुछ तोड़ा।

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

FAQ

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

Helsinki University of Technology के एक शोधकर्ता Tatu Ylönen ने 1995 में विश्वविद्यालय के नेटवर्क पर पासवर्ड स्निफिंग हमले के बाद SSH लिखा था। उस समय के रिमोट लॉगिन टूल्स, telnet और rlogin, पासवर्ड को नेटवर्क पर पठनीय टेक्स्ट के रूप में भेजते थे। इसलिए, साझा नेटवर्क सेगमेंट की निगरानी करने वाला कोई भी व्यक्ति गुजरते हुए क्रेडेंशियल्स को इकट्ठा कर सकता था। उन्होंने जुलाई 1995 में इस प्रोग्राम को फ्रीवेयर के रूप में जारी किया। उस वर्ष के अंत तक पचास देशों में इसके लगभग 20,000 उपयोगकर्ता थे, और दिसंबर 1995 में उन्होंने SSH Communications Security की स्थापना की।

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

ये अलग-अलग प्रोटोकॉल हैं और इनमें कोई वायर कम्पैटिबिलिटी नहीं है। SSH-1 एक एकल मोनोलिथिक प्रोटोकॉल था जो अखंडता (integrity) के लिए CRC-32 का उपयोग करता था और क्लाइंट को सर्वर की RSA कुंजियों के तहत एन्क्रिप्टेड सेशन की (session key) भेजने के लिए कहता था। SSH-2 काम को ट्रांसपोर्ट लेयर, ऑथेंटिकेशन लेयर और कनेक्शन लेयर (RFCs 4251 से 4254, जनवरी 2006) में विभाजित करता है, अखंडता के लिए HMAC का उपयोग करता है, और Diffie-Hellman के साथ सेशन की (session keys) प्राप्त करता है। इस कारण, यदि बाद में होस्ट की (host key) चोरी भी हो जाए, तो भी रिकॉर्ड किया गया ट्रैफिक निजी रहता है। SSH-1 को चरणों में OpenSSH से हटा दिया गया, जो अक्टूबर 2017 में वर्जन 7.6 के साथ समाप्त हुआ।

OpenSSH ने मूल SSH इम्प्लीमेंटेशन की जगह क्यों ली?

मूल SSH का विकास एक प्रतिबंधित लाइसेंस वाले कमर्शियल प्रोडक्ट में बदल गया, और अंतिम स्वतंत्र रूप से पुन: प्रयोज्य रिलीज ssh 1.2.12 थी। 1999 की शुरुआत में Björn Grönvall ने उस रिलीज को OSSH के रूप में पुनर्जीवित किया, और OpenBSD टीम ने OSSH को OpenSSH में फोर्क किया, जिसे 1 दिसंबर 1999 को OpenBSD 2.6 के साथ रिलीज किया गया। OpenBSD को अपने बेस सिस्टम के लिए एक अप्रतिबंधित लाइसेंस के तहत ऑडिट किए गए कोड की आवश्यकता थी, और इन्हीं दो गुणों के कारण अन्य सभी ऑपरेटिंग सिस्टम पोर्टेबल ब्रांच के माध्यम से एक ही इम्प्लीमेंटेशन का उपयोग कर पाते हैं।

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

क्योंकि क्लाइंट ने उस सर्वर को पहले कभी नहीं देखा है और उसके पास तुलना करने के लिए कोई की (key) नहीं है। केवल एन्क्रिप्शन एक ईमानदार सर्वर को रास्ते के बीच में बैठे मशीन से अलग नहीं कर सकता है, इसलिए SSH सर्वर की पहचान की (key) से करता है और जो देखा उसे ~/.ssh/known_hosts में रिकॉर्ड करता है। पहला कनेक्शन वह क्षण है जब चेक करने के लिए कोई संग्रहीत मान नहीं होता है, यही कारण है कि क्लाइंट आपसे पूछता है। फिंगरप्रिंट की तुलना उस फिंगरप्रिंट से करें जो आपको प्रोवाइडर कंसोल या सर्वर से मिला है, और किसी भी बाद के REMOTE HOST IDENTIFICATION HAS CHANGED संदेश को तब तक वास्तविक घटना मानें जब तक आप इसका कारण स्पष्ट न कर लें।

अपग्रेड के बाद पुरानी SSH कुंजियाँ (keys) काम करना क्यों बंद कर देती हैं?

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