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

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

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

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

इस पृष्ठ पर भरोसा न करें, commands चलाएं

नीचे दिए गए प्रत्येक algorithm का नाम उस command से आता है जिसे आप स्वयं चला सकते हैं। यह जानबूझकर किया गया है। डिफ़ॉल्ट मान प्रत्येक OpenSSH release के साथ बदलते हैं, इसलिए दो साल पहले लिखा गया कोई guide ऐसे 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 सर्वर के लिए भी यही काम करता है। प्रत्येक preference order में एक single kexalgorithms line print करता है, और उस पर पहला नाम उस side की पहली पसंद होता है। वही line wire पर जाती है।

यह अंतर केवल सैद्धांतिक नहीं है। 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 (module-lattice key encapsulation mechanism, जिसे FIPS 203 के रूप में मानकीकृत किया गया है) को parameter set 768 पर चलाता है, साथ ही X25519 elliptic curve Diffie-Hellman का उपयोग करता है, और दोनों आउटपुट को session key में मिला देता है।

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

debug1: kex: algorithm: curve25519-sha256

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

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

ssh -v को इस एक लाइन से अधिक के लिए जानना उपयोगी है, क्योंकि यही वह आउटपुट है जहाँ आप Permission denied (publickey) विफलता का पता लगाते हैं जब लॉगिन को पूरी तरह से अस्वीकार कर दिया जाता है।

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

debug1: kex: host key algorithm: ssh-ed25519

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

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

• 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 registered नाम, sntrup761x25519-sha512, दिया, इसलिए नए builds इसे दोनों spellings के अंतर्गत सूचीबद्ध करते हैं।
• 10.0, जिसे 2025-04-09 को release किया गया, ने mlkem768x25519-sha256 को key agreement के लिए default बना दिया।
• 10.1, जिसे 2025-10-06 को release किया गया, ने एक client warning जोड़ी जब कोई connection बिना post-quantum half के key exchange negotiate करता है। यह ssh_config में WarnWeakCrypto option द्वारा नियंत्रित होता है और default रूप से चालू रहता है।

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

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

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

• 22.04 LTS में 1:8.9p1 आता है, जो 9.0 default से पुराना है, इसलिए एक stock install curve25519-sha256 negotiate करता है।
• 24.04 LTS में 1:9.6p1 आता है, जो 9.0 के बाद और 9.9 से पहले का है, इसलिए इसका default sntrup761x25519-sha512@openssh.com है और इसमें ML-KEM नहीं है।
• 25.10 में 1:10.0p1 आता है, जिसका default mlkem768x25519-sha256 है।
• 26.04 LTS में 1:10.2p1 आता है, जो 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) या 'अभी स्टोर करें, बाद में डिक्रिप्ट करें' कहा जाता है। इसके लिए हमलावर को वर्तमान में किसी चतुराई की आवश्यकता नहीं है। इसके लिए केवल डिस्क स्पेस और धैर्य की आवश्यकता है।

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

हाइब्रिड का अर्थ है कि दोनों एल्गोरिदम चलते हैं और दोनों के परिणाम सेशन की (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 प्रकार और कोई post-quantum user key प्रकार नहीं है, और ssh-keygen के पास आपको देने के लिए ऐसा कुछ नहीं है। यदि कोई guide आपको ऐसा key generate करने के लिए कह रही है, तो वह ऐसे software का वर्णन कर रही है जो अभी अस्तित्व में ही नहीं है।

उसी server पर TLS एक अलग प्रश्न है जिसका उत्तर भी अलग है। TLS (transport layer security) वह है जिसे आपका 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 आपको उस version पर रखता है जो आपका Ubuntu release प्रदान करता है, और नए Ubuntu release पर जाने से ही आप नए OpenSSH पर पहुँचते हैं। unattended security upgrades को चालू करने से ये patches बिना आपके याद रखे apply हो जाते हैं। किसी 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 कर लेता, वह चुपचाप उस सूची में बचे हुए किसी भी algorithm पर गिर जाता है। किसी भी 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 classical हैं। इससे अधिक व्यापक कुछ भी ऐसे नाम के साथ आना चाहिए जिसे आप 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 को रिलीज़ किया गया था, ने चेतावनी देना शुरू किया जब कनेक्शन में कोई भी post-quantum एक्सचेंज नेगोशिएट नहीं होता है। जांचें कि आपका अपना बिल्ड 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 सेट करने से यह संदेश छिप जाता है और कनेक्शन उतना ही कमजोर बना रहता है जितना वह पहले था।