Ubuntu पर Post-Quantum SSH कैसे काम करता है

Post-quantum SSH में क्या बदलाव आया है

Post-quantum SSH अधिकांश उपयोगकर्ताओं के लिए पहले से ही चालू है, और किसी को भी इसे कॉन्फ़िगर करने की आवश्यकता नहीं पड़ी। एक वर्तमान OpenSSH client जब एक वर्तमान OpenSSH server से जुड़ता है, तो वह डिफ़ॉल्ट रूप से एक hybrid post-quantum key exchange का चयन करता है। इससे session key उस हमलावर के खिलाफ सुरक्षित रहती है जो आज आपके traffic को रिकॉर्ड करता है और वर्षों बाद उसे डिक्रिप्ट करने का प्रयास करता है। यह सुरक्षा वास्तविक है, लेकिन यह "quantum-safe SSH" वाक्यांश के सुझाव से कहीं अधिक सीमित है।

सबसे पहले दो शब्दों को समझें। SSH (secure shell) वह protocol है जिसके माध्यम से आप server में login करते हैं। Key exchange, जिसे आमतौर पर "kex" लिखा जाता है, हर SSH connection का पहला चरण है: दोनों छोर एक shared secret पर सहमत होते हैं, और वह secret उसके बाद आने वाले सभी डेटा को encrypt करता है। केवल key exchange वाला हिस्सा ही बदला है। इसके अलावा कुछ भी नहीं बदला है।

इस पेज पर भरोसा न करें, commands चलाएं

नीचे दिए गए प्रत्येक algorithm का नाम उस command से आता है जिसे आप स्वयं चला सकते हैं। यह जानबूझकर किया गया है। डिफ़ॉल्ट मान प्रत्येक OpenSSH release के साथ बदलते रहते हैं, इसलिए दो साल पहले लिखा गया कोई गाइड ऐसे algorithm का नाम ले सकता है जिसे आपकी machine अब प्राथमिकता नहीं देती, और उसके पास आपको बताने का कोई तरीका नहीं है। इन commands को सीखें और आपको इस विषय पर लेखों की आवश्यकता नहीं पड़ेगी, जिसमें यह लेख भी शामिल है।

शुरुआत वहां से करें जो आपका build करना जानता है।

ssh -V
ssh -Q kex

ssh -V एक version line print करता है जो OpenSSH_ से शुरू होती है, जिसके बाद Ubuntu package suffix और OpenSSL version आता है। ssh -Q kex प्रति line एक key exchange algorithm print करता है। Post-quantum support वाले build पर आपको उस सूची में mlkem768x25519-sha256 और sntrup761x25519-sha512@openssh.com जैसे नाम मिलेंगे, जो curve25519-sha256 जैसे शास्त्रीय नामों के साथ मौजूद होंगे।

आपका build जो support करता है, वह वही नहीं है जो वह offer करता है

यह वह अंतर है जिसे अधिकांश पोस्ट नजरअंदाज कर देते हैं। ssh -Q kex एक सवाल का जवाब देता है: यह binary क्या कर सकता है। यह उस सवाल का जवाब नहीं देता जिसकी आपको परवाह है: यह connection वास्तव में क्या propose करेगा। ये दोनों सूचियाँ अलग हैं, और इनके बीच का अंतर ही वह जगह है जहाँ पुरानी सलाह वास्तविक नुकसान पहुँचाती है।

ssh -G example.com | grep -i '^kexalgorithms'
sudo sshd -T | grep -i '^kexalgorithms'

ssh -G <host> उस host के लिए client का प्रभावी configuration print करता है, जो ~/.ssh/config और /etc/ssh/ssh_config के लागू होने के बाद बचता है। sshd -T सर्वर के लिए भी यही काम करता है। प्रत्येक प्राथमिकता क्रम में एक एकल kexalgorithms लाइन print करता है, और उस पर पहला नाम उस पक्ष की पहली पसंद होता है। वही लाइन network पर भेजी जाती है।

यह अंतर केवल सैद्धांतिक नहीं है। OpenSSH 8.5, जिसे 2021-03-03 को release किया गया था, ने sntrup761x25519-sha512@openssh.com को जोड़ा और जानबूझकर इसे default सूची से बाहर रखा। उस release पर ssh -Q kex उस algorithm को दिखाता है और ssh -G नहीं दिखाता है, जिसका अर्थ है कि binary एक post-quantum key exchange कर सकता है, लेकिन कोई भी connection इसे करने के लिए नहीं कहता है।

आपके कनेक्शन द्वारा नेगोशिएट किए गए एल्गोरिदम को पढ़ें

ssh -v example.com 2>&1 | grep 'kex: algorithm'

एक वर्तमान क्लाइंट और एक वर्तमान सर्वर के बीच, यह प्रिंट होता है:

debug1: kex: algorithm: mlkem768x25519-sha256

mlkem768x25519-sha256 एक हाइब्रिड है। यह ML-KEM (मॉड्यूल-लैटिस की एनकैप्सुलेशन मैकेनिज्म, जिसे FIPS 203 के रूप में मानकीकृत किया गया है) को पैरामीटर सेट 768 पर चलाता है, साथ ही X25519 एलिप्टिक कर्व Diffie-Hellman का उपयोग करता है, और दोनों आउटपुट को सेशन की (session key) में मिला देता है।

पुराने सर्वर के विरुद्ध आपको इसके बजाय यह दिखाई दे सकता है:

debug1: kex: algorithm: curve25519-sha256

उस नाम में कोई पोस्ट-क्वांटम हिस्सा नहीं है। curve25519-sha256 केवल एलिप्टिक कर्व Diffie-Hellman है, और एक बड़ा क्वांटम कंप्यूटर इसे तोड़ सकता है। यही एकमात्र कारण है कि डिफ़ॉल्ट को बदला गया है।

एक नेगोशिएशन नियम बताता है कि क्यों एक पुरानी मशीन सेशन को पीछे रोक कर रखती है। क्लाइंट अपनी सूची प्राथमिकता के क्रम में भेजता है, सर्वर अपनी सूची भेजता है, और चुना गया एल्गोरिदम क्लाइंट की सूची का वह पहला नाम होता है जो सर्वर की सूची में भी मौजूद हो। क्लाइंट की प्राथमिकता जीतती है, इसलिए दोनों सिरों में से पुराना सिरा यह तय करता है कि आप सूची में कितनी ऊपर तक पहुँचते हैं। अपने लैपटॉप को अपग्रेड करने से वह सेशन अपग्रेड नहीं होता जो ऐसे सर्वर से जुड़ा है जिसने ML-KEM के बारे में कभी नहीं सुना है।

grep को हटा दें और ssh -v नेगोशिएशन का बाकी हिस्सा दिखाता है, जिसमें वह लाइन भी शामिल है जिसके बारे में अगला सेक्शन है:

debug1: kex: host key algorithm: ssh-ed25519

किस OpenSSH release ने hybrid exchange को default बनाया

Upstream release notes एक स्पष्ट क्रम प्रदान करते हैं। संस्करण संख्याओं की तुलना में तिथियां अधिक महत्वपूर्ण हैं, क्योंकि वे दर्शाती हैं कि यह कितनी देर से चुपचाप चल रहा है।

• 8.5, जिसे 2021-03-03 को release किया गया, ने sntrup761x25519-sha512@openssh.com को जोड़ा और इसे default रूप से disabled रखा।
• 9.0, जिसे 2022-04-08 को release किया गया, ने इसे चालू कर दिया। Notes में लिखा है कि OpenSSH "default रूप से hybrid Streamlined NTRU Prime + x25519 key exchange method का उपयोग करेगा"। यह वह release है जहाँ post-quantum key exchange सामान्य स्थिति बन गया।
• 9.9, जिसे 2024-09-19 को release किया गया, ने mlkem768x25519-sha256 को दूसरे विकल्प के रूप में जोड़ा। उसी release ने पुरानी विधि को उसका IANA पंजीकृत नाम, sntrup761x25519-sha512 दिया, इसलिए नए builds इसे दोनों वर्तनी के अंतर्गत सूचीबद्ध करते हैं।
• 10.0, जिसे 2025-04-09 को release किया गया, ने mlkem768x25519-sha256 को key agreement के लिए default बना दिया।
• 10.1, जिसे 2025-10-06 को release किया गया, ने एक client चेतावनी जोड़ी जब कोई connection बिना post-quantum half के key exchange negotiate करता है। यह ssh_config में WarnWeakCrypto विकल्प द्वारा नियंत्रित होता है और default रूप से चालू रहता है।

अप्रैल 2022 वह तारीख है जिसे याद रखना चाहिए। OpenSSH 9.0 या उससे नए संस्करण चलाने वाली मशीनों का कोई भी जोड़ा तब से post-quantum key exchange कर रहा है, बिना किसी configuration के और ssh टाइप करने वाले व्यक्ति को कोई घोषणा किए बिना।

कौन सा Ubuntu release इसे ship करता है

Ubuntu release के समय OpenSSH के एक version को freeze कर देता है, और फिर version number बदले बिना उसमें security fixes को backport करता है। इसलिए, आप जो Ubuntu release चला रहे हैं, वही आपके default algorithm को निर्धारित करता है। किसी सूची पर भरोसा करने के बजाय अपने सामने मौजूद machine पर ssh -V चलाकर जाँचें। अगस्त 2026 तक archive में ये versions मौजूद हैं:

• 22.04 LTS 1:8.9p1 को ship करता है, जो 9.0 default से पहले का है, इसलिए एक stock install curve25519-sha256 पर negotiate करता है।
• 24.04 LTS 1:9.6p1 को ship करता है, जो 9.0 के बाद और 9.9 से पहले का है, इसलिए इसका default sntrup761x25519-sha512@openssh.com है और इसमें ML-KEM नहीं है।
• 25.10 1:10.0p1 को ship करता है, जिसका default mlkem768x25519-sha256 है।
• 26.04 LTS 1:10.2p1 को ship करता है, जिसका default mlkem768x25519-sha256 है और यह उन connections के बारे में चेतावनी देता है जो post-quantum नहीं हैं।

वास्तविक machines के एक pair के साथ काम करें। एक 26.04 laptop, 24.04 server से connect होता है। client की पहली पसंद, mlkem768x25519-sha256, 9.6 server की सूची में नहीं है। client की अगली post-quantum पसंद जो server के पास उपलब्ध है, वह sntrup761x25519-sha512@openssh.com है, और यही वह नाम है जिसे ssh -v report करता है। session key exchange पर post-quantum है, जो 2024 में बने server के विरुद्ध है, जिसमें किसी के द्वारा कुछ भी configure नहीं किया गया है।

22.04 का मामला दूसरी दिशा में जाता है, और यह स्पष्ट करता है कि क्यों केवल ssh -Q kex भ्रामक हो सकता है। OpenSSH 8.9 sntrup761x25519-sha512@openssh.com नाम को जानता है, इसलिए उस box पर ssh -Q kex इसे list करता है, लेकिन default proposal इसे बाहर रखता है, इसलिए negotiation curve25519-sha256 पर तय होता है। OpenSSH 10.1 या उससे नए client से, connection यह बताता है:

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

वह चेतावनी उस server के बारे में एक तथ्य है जिस तक आप पहुँच रहे हैं, न कि आपके client के बारे में। इसका समाधान server को upgrade करना है। WarnWeakCrypto no set करने से message हट जाता है और connection के बारे में कुछ भी नहीं बदलता है।

हाइब्रिड क्यों, और 'अभी इकट्ठा करें, बाद में डिक्रिप्ट करें' का क्या अर्थ है

खतरा स्पष्ट है। एक हमलावर जो आपके ट्रैफिक को देख सकता है, वह आज एन्क्रिप्टेड बाइट्स को रिकॉर्ड करता है और उन्हें स्टोर कर लेता है। वे आज उन्हें नहीं पढ़ सकते। वे उन्हें तब तक रखते हैं जब तक कि X25519 को तोड़ने के लिए पर्याप्त बड़ा क्वांटम कंप्यूटर मौजूद न हो जाए, और फिर वे उन्हें पढ़ लेते हैं। इसे 'अभी इकट्ठा करें, बाद में डिक्रिप्ट करें' (harvest now, decrypt later) या 'अभी स्टोर करें, बाद में डिक्रिप्ट करें' कहा जाता है। यह वर्तमान में हमलावर से किसी चतुराई की मांग नहीं करता है। यह केवल डिस्क स्पेस और धैर्य की मांग करता है।

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

हाइब्रिड का अर्थ है कि दोनों एल्गोरिदम चलते हैं और दोनों के परिणाम सेशन की (session key) में फीड होते हैं। mlkem768x25519-sha256 के पीछे के सीक्रेट को रिकवर करने के लिए एक हमलावर को ML-KEM 768 और X25519 दोनों को तोड़ना होगा। यह पेयरिंग जानबूझकर की गई है: ML-KEM, X25519 की तुलना में बहुत नया है और क्रिप्टानलिस्ट्स द्वारा हमले के तहत इसे बहुत कम समय मिला है, इसलिए नए एल्गोरिदम में पाई गई कोई खामी आपको उस सुरक्षा से वंचित नहीं करती जो आपके पास पहले से थी।

क्या सुरक्षित है और क्या नहीं

Key exchange सुरक्षित है। आपके session को encrypt करने वाला shared secret एक hybrid exchange से प्राप्त हुआ है, इसलिए आज रिकॉर्ड किया गया session भविष्य में quantum computers के आने पर भी readable नहीं होगा।

Host key सुरक्षित नहीं है। debug1: kex: host key algorithm: ssh-ed25519 लाइन एक classical signature का नाम बताती है, और यही बात rsa-sha2-512 तथा ECDSA (elliptic curve digital signature algorithm) प्रकारों पर भी लागू होती है। एक attacker जिसके पास कार्यशील quantum computer हो, वह उस signature को forge करके आपके server का रूप धारण कर सकता है, लेकिन यह केवल भविष्य में live connection के दौरान ही संभव है, न कि अभी रिकॉर्ड किए गए traffic के विरुद्ध।

आपका login key भी सुरक्षित नहीं है। ~/.ssh/id_ed25519 में मौजूद key भी उसी प्रकार का classical signature है, और उस पर भी यही तर्क लागू होता है। इस वर्ष उस key को जो चीज़ सुरक्षित रखती है, वह यह है कि वह कहाँ स्थित है और उसे कौन पढ़ सकता है, इसलिए sensible SSH key management आपके वास्तविक जोखिम को इस पृष्ठ पर दिए गए किसी भी algorithm के नाम की तुलना में बहुत अधिक कम कर देता है।

इनमें से किसी भी चीज़ के बारे में आपको कुछ करने की आवश्यकता नहीं है, क्योंकि अभी स्विच करने के लिए कुछ भी उपलब्ध नहीं है। OpenSSH ने कहा है कि post-quantum signature support भविष्य के release में आएगा। जब तक यह software release नहीं होता, OpenSSH में कोई post-quantum host key type और कोई post-quantum user key type नहीं है, और ssh-keygen के पास आपको देने के लिए ऐसा कुछ नहीं है। यदि कोई guide आपको ऐसा key generate करने के लिए कह रही है, तो वह ऐसे software का वर्णन कर रही है जो अभी अस्तित्व में ही नहीं है।

उसी server पर TLS एक अलग प्रश्न है जिसका उत्तर भी अलग है। TLS (transport layer security) वह protocol है जिस पर आपका web server port 443 पर बात करता है, और यह एक अलग codebase है जिसका schedule भी अलग है। OpenSSH को upgrade करने से वहाँ कुछ भी नहीं बदलता। यदि आप a self-signed certificate for a private service on the same VPS चला रहे हैं, तो उसका signature और उसका key exchange OpenSSL और आपके web server द्वारा तय किया जाता है, इसलिए उस stack के बारे में उसी के संदर्भ में जानकारी प्राप्त करें।

एक समझदार ऑपरेटर अब क्या करता है

OpenSSH को current रखें, और बस इतना ही करें। इस समस्या के लिए यही पूरी रणनीति है। sudo apt update && sudo apt upgrade आपको उस वर्ज़न पर रखता है जो आपका Ubuntu release प्रदान करता है, और एक नए Ubuntu release पर जाना ही आपको नए OpenSSH पर ले जाता है। unattended security upgrades को चालू करने से वे patches आपके याद रखे बिना ही लागू हो जाते हैं। किसी algorithm के नाम के पीछे भागने के लिए source से OpenSSH build करना एक खराब सौदा है, क्योंकि आप सर्वर की सबसे अधिक exposed service के लिए distribution के security updates को खो देते हैं। यदि आप फिर भी source fetch करते हैं, तो build करने से पहले download की गई फाइल को उसके published checksum से verify करें।

KexAlgorithms लाइन को खुद न लिखें। यह वह एकमात्र कार्य है जो भरोसेमंद रूप से चीजों को बदतर बना देता है। 2018 की एक hardening guide आपको ऐसी सूची देती है जो 2018 में सही थी, और उसे sshd_config में paste करने से वह default सूची को जोड़ने के बजाय replace कर देती है। तब से आविष्कार किया गया हर algorithm अब बाहर हो जाता है, इसलिए जो सर्वर अपने आप mlkem768x25519-sha256 negotiate कर सकता था, वह चुपचाप उस सूची में बचे हुए किसी भी विकल्प पर गिर जाता है। किसी भी inherited सर्वर पर sudo sshd -T | grep -i '^kexalgorithms' चलाएं। यदि वह लाइन उसी release के fresh install की तुलना में छोटी है, तो किसी ने उसे pin किया है।

यदि आपके पास सूची बदलने का कोई वास्तविक कारण है, तो उसे replace करने के बजाय उसमें जोड़ें। OpenSSH एक leading + को append के रूप में, एक leading - को remove के रूप में, और एक leading ^ को सामने ले जाने के रूप में पढ़ता है।

KexAlgorithms ^mlkem768x25519-sha256

उस पर भरोसा करने से पहले फाइल का परीक्षण करें। sudo sshd -t configuration को parse करता है और valid होने पर कुछ भी print नहीं करता है। एक KexAlgorithms लाइन जिसमें ऐसे algorithm का नाम हो जो build में नहीं है, वह sshd को start होने से रोक देती है, और remote box पर इसका मतलब है कि आप वापस अंदर नहीं जा पाएंगे, इसलिए काम करते समय एक दूसरा session खुला रखें। जब दोनों पक्षों की सूचियां मेल खाना बंद कर देती हैं, तो client इसे स्पष्ट रूप से बताता है:

Unable to negotiate with 203.0.113.10 port 22: no matching key exchange method found. Their offer: curve25519-sha256,ecdh-sha2-nistp256

"quantum-safe" मार्केटिंग को केवल एक परत (layer) के बारे में दावा समझें। जो vendor किसी product को quantum-safe कहता है, वह उस परत का वर्णन कर रहा होता है जिसका उसने नाम लिया है, और वह परत आमतौर पर कहीं न कहीं एक key exchange होती है। algorithm का नाम और वह protocol पूछें जिस पर यह लागू होता है। अगस्त 2026 में OpenSSH के लिए दावे का ईमानदार वर्ज़न यह है कि key exchange हाइब्रिड post-quantum है जबकि signatures क्लासिकल हैं। इससे अधिक व्यापक कुछ भी ऐसे नाम के साथ आना चाहिए जिसे आप ssh -Q kex output में ढूंढ सकें।

बोरिंग काम करते रहें। एक post-quantum key exchange अनुमान लगाने योग्य password, या किसी laptop पर copy की गई private key जो बाद में चोरी हो जाती है, उसके खिलाफ कुछ नहीं करता है। यही वे चीजें हैं जो वास्तव में सर्वर को breach करती हैं, और VPS पर standard SSH hardening अभी भी लगभग सारा भार उठाती है। यदि यहाँ negotiation के चरण अपरिचित थे, तो SSH connect होने पर क्या करता है उन चरणों को कवर करता है जिन्हें यह पेज मानता है कि आप जानते हैं।

FAQ

क्या मेरा SSH कनेक्शन पहले से ही post-quantum है?

ssh -v yourserver 2>&1 | grep 'kex: algorithm' चलाएं और इसके द्वारा प्रिंट किए गए नाम को पढ़ें। mlkem768x25519-sha256 और sntrup761x25519-sha512@openssh.com हाइब्रिड post-quantum एक्सचेंज हैं। curve25519-sha256, ecdh-sha2-nistp256 और कोई भी diffie-hellman-group नाम क्लासिकल हैं। दोनों सिरों पर ऐसे वर्ज़न की आवश्यकता होती है जो post-quantum नाम प्रदान करता हो, क्योंकि नेगोशिएशन क्लाइंट की पहली पसंद को चुनता है जिसे सर्वर भी सपोर्ट करता है, इसलिए पुरानी मशीन सीमा तय कर देती है।

किस OpenSSH रिलीज़ ने post-quantum की-एक्सचेंज को डिफ़ॉल्ट बनाया?

OpenSSH 9.0, जिसे 2022-04-08 को रिलीज़ किया गया था, ने sntrup761x25519-sha512@openssh.com को डिफ़ॉल्ट की-एक्सचेंज बनाया। OpenSSH 9.9, जिसे 2024-09-19 को रिलीज़ किया गया था, ने mlkem768x25519-sha256 को जोड़ा, और OpenSSH 10.0, जिसे 2025-04-09 को रिलीज़ किया गया था, ने उसे डिफ़ॉल्ट बना दिया। OpenSSH 10.1, जिसे 2025-10-06 को रिलीज़ किया गया था, ने चेतावनी देना शुरू किया जब कोई कनेक्शन इनमें से किसी का भी नेगोशिएशन नहीं करता है। जांचें कि आपका अपना बिल्ड ssh -Q kex और ssh -G <host> के साथ क्या करता है, क्योंकि आपका Ubuntu रिलीज़ यह तय करता है कि आपके पास इनमें से कौन सा है।

क्या मुझे post-quantum SSH की (key) जनरेट करनी चाहिए?

नहीं, क्योंकि OpenSSH में ऐसा कोई की-टाइप नहीं है। अब तक का post-quantum कार्य की-एक्सचेंज को कवर करता है, जिसके लिए आपसे किसी की-फाइल या किसी कॉन्फ़िगरेशन की आवश्यकता नहीं है। होस्ट कीज़ और लॉगिन कीज़ अभी भी Ed25519 और RSA जैसे क्लासिकल सिग्नेचर हैं, और अपस्ट्रीम ने कहा है कि post-quantum सिग्नेचर भविष्य की रिलीज़ में आएंगे। Ed25519 की का उपयोग करना जारी रखें और जहां यह स्टोर है उसे सुरक्षित रखें।

ssh चेतावनी क्यों देता है कि मेरा कनेक्शन post-quantum नहीं है?

OpenSSH 10.1 और नए वर्ज़न ** WARNING: connection is not using a post-quantum key exchange algorithm. प्रिंट करते हैं जब नेगोशिएट किए गए एक्सचेंज में कोई post-quantum हाफ नहीं होता है। यह चेतावनी सर्वर के बारे में है, आपके क्लाइंट के बारे में नहीं, क्योंकि आपके क्लाइंट ने post-quantum नाम का प्रस्ताव दिया था और सर्वर ने उनमें से किसी को भी स्वीकार नहीं किया। सर्वर के OpenSSH को अपग्रेड करें, या जांचें कि किसी ने इसके sshd_config में ऐसी KexAlgorithms लाइन तो पिन नहीं की है जो आधुनिक नामों को बाहर करती हो। WarnWeakCrypto no सेट करने से संदेश छिप जाता है और कनेक्शन उतना ही कमजोर बना रहता है जितना वह पहले था।