Ubuntu वर Post-Quantum SSH मध्ये काय बदलले?

Post-quantum SSH मध्ये काय बदलले

बहुतेक वापरकर्त्यांसाठी post-quantum SSH आधीपासून सक्षम आहे आणि त्यासाठी कोणतेही configuration करावे लागलेले नाही. सध्याचा OpenSSH client सध्याच्या OpenSSH server शी जोडला गेल्यावर तो default म्हणून hybrid post-quantum key exchange निवडतो. त्यामुळे आज तुमचा network traffic नोंदवून ठेवणारा आणि अनेक वर्षांनी तो decrypt करणारा attacker session key विरुद्ध प्रभावी ठरणार नाही. हे संरक्षण प्रत्यक्षात उपलब्ध आहे. मात्र, "quantum-safe SSH" या संज्ञेतून सूचित होते त्यापेक्षा त्याची व्याप्ती मर्यादित आहे.

प्रथम दोन संज्ञा समजून घेऊ. SSH (secure shell) हा असा protocol आहे ज्याद्वारे तुम्ही server मध्ये login करता. Key exchange, ज्याला सामान्यतः "kex" असे लिहिले जाते, हा प्रत्येक SSH connection मधील पहिला टप्पा असतो. दोन्ही बाजू shared secret वर सहमत होतात आणि त्यानंतरचे सर्व communication encrypt करण्यासाठी तो secret वापरला जातो. बदललेला भाग key exchange आहे. इतर कोणताही भाग बदललेला नाही.

या पृष्ठावर विश्वास ठेवू नका; commands स्वतः चालवा

खालील प्रत्येक algorithm चे नाव तुम्ही स्वतः चालवू शकता अशा command मधून मिळते. हे जाणीवपूर्वक केले आहे. प्रत्येक OpenSSH release सोबत default बदलतो. त्यामुळे दोन वर्षांपूर्वी लिहिलेल्या मार्गदर्शकात तुमच्या machine ला आता प्राधान्य नसलेल्या algorithm चे नाव असू शकते आणि ते तुम्हाला हे सांगू शकत नाही. या commands शिका. मग या विषयावरील, या पृष्ठासह, इतर लेखांवर अवलंबून राहण्याची गरज उरणार नाही.

तुमच्या build ला कोणती कार्ये करता येतात, ते प्रथम तपासा.

ssh -V
ssh -Q kex

ssh -V, OpenSSH_ पासून सुरू होणारी version line, त्यानंतर Ubuntu package suffix आणि OpenSSL version छापते. ssh -Q kex प्रत्येक key exchange algorithm स्वतंत्र ओळीत छापते. post-quantum support असलेल्या build मध्ये त्या यादीत mlkem768x25519-sha256 आणि sntrup761x25519-sha512@openssh.com यांसारखी नावे आढळतील. ती curve25519-sha256 सारख्या classical नावांच्या शेजारी दिसतील.

तुमच्या build ला काय समर्थन आहे आणि ते प्रत्यक्षात काय प्रस्तावित करते हे वेगवेगळे आहे

बहुतेक लेख हीच महत्त्वाची तफावत वगळतात. ssh -Q kex एका प्रश्नाचे उत्तर देते: या binary कडून काय करता येऊ शकते? तुम्हाला महत्त्वाच्या असलेल्या प्रश्नाचे ते उत्तर देत नाही: हे connection प्रत्यक्षात काय प्रस्तावित करेल? या दोन याद्या वेगळ्या असतात. त्यांच्यातील तफावतीमुळे जुन्या सल्ल्याचे गंभीर दुष्परिणाम होतात.

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

ssh -G <host> ~/.ssh/config आणि /etc/ssh/ssh_config लागू केल्यानंतर, त्या host साठी client ची प्रभावी configuration दाखवते. sshd -T server साठी हेच करते. प्रत्येक command preference order नुसार एकच kexalgorithms line दाखवते. त्या line वरील पहिले नाव म्हणजे त्या बाजूची पहिली पसंती. Network वर पाठवली जाणारी माहिती हीच line असते.

ही तफावत केवळ सैद्धांतिक नाही. 2021-03-03 रोजी release झालेल्या OpenSSH 8.5 मध्ये sntrup761x25519-sha512@openssh.com समाविष्ट करण्यात आले; मात्र ते default list मधून जाणीवपूर्वक वगळण्यात आले. त्या release मध्ये ssh -Q kex हा algorithm दाखवते, पण ssh -G दाखवत नाही. याचा अर्थ binary कडे post-quantum key exchange करण्याची क्षमता आहे, पण कोणतेही connection त्याची मागणी करत नाही.

तुमच्या कनेक्शनने निवडलेला algorithm वाचा

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

सध्याचा client आणि सध्याचा server यांच्यामध्ये याचा output असा दिसतो:

debug1: kex: algorithm: mlkem768x25519-sha256

mlkem768x25519-sha256 हा hybrid आहे. यामध्ये parameter set 768 सह ML-KEM (module-lattice key encapsulation mechanism, FIPS 203 म्हणून standardised) आणि X25519 elliptic curve Diffie-Hellman वापरले जातात. दोन्हींचे output एकत्र करून session key तयार केली जाते.

जुन्या server विरुद्ध तुम्हाला त्याऐवजी हे दिसू शकते:

debug1: kex: algorithm: curve25519-sha256

या नावात post-quantum भाग नाही. curve25519-sha256 हे स्वतंत्रपणे elliptic curve Diffie-Hellman आहे आणि मोठा quantum computer ते मोडू शकतो. default बदलण्याचे हेच संपूर्ण कारण आहे.

एक negotiation rule समजून घेतल्यास एक जुना machine session मागे का ठेवतो हे स्पष्ट होते. client आपली यादी preference order मध्ये पाठवतो आणि server आपली यादी पाठवतो. त्यानंतर client च्या यादीतील, server वरही असलेले पहिले नाव निवडले जाते. client ची preference लागू होते. त्यामुळे दोन्ही endpoints पैकी जुना endpoint यादीत किती पुढे जाता येईल हे ठरवतो. तुमचा laptop upgrade केल्याने ML-KEM बद्दल कधीही ऐकले नसलेल्या server सोबतचे session upgrade होत नाही.

ssh -v ही माहिती या एका ओळीपेक्षा अधिक कारणांसाठी उपयुक्त आहे. Login पूर्णपणे नाकारला गेल्यावर Permission denied (publickey) failure शोधण्यासाठी याच output मध्ये माहिती मिळते.

grep आणि ssh -v काढून टाका. त्यानंतर negotiation चा उर्वरित भाग दिसेल. त्यामध्ये पुढील section संबंधित असलेली line देखील असेल:

debug1: kex: host key algorithm: ssh-ed25519

कोणत्या OpenSSH release मध्ये hybrid exchange default करण्यात आला

Upstream release notes मध्ये याचा स्पष्ट क्रम दिला आहे. Version numbers पेक्षा तारखा अधिक महत्त्वाच्या आहेत, कारण हे वैशिष्ट्य किती काळापासून शांतपणे कार्यरत आहे ते त्यातून दिसते.

• 8.5, 2021-03-03 रोजी released, ने sntrup761x25519-sha512@openssh.com जोडले आणि ते default ने disabled ठेवले.
• 9.0, 2022-04-08 रोजी released, ने ते enabled केले. Notes मध्ये OpenSSH default ने “hybrid Streamlined NTRU Prime + x25519 key exchange method वापरेल” असे म्हटले आहे. या release पासून post-quantum key exchange ही सामान्य default पद्धत झाली.
• 9.9, 2024-09-19 रोजी released, ने दुसरा पर्याय म्हणून mlkem768x25519-sha256 जोडला. याच release मध्ये जुन्या पद्धतीला IANA-registered नाव sntrup761x25519-sha512 देण्यात आले. त्यामुळे नवीन builds मध्ये ती दोन्ही नावांनी सूचीबद्ध दिसते.
• 10.0, 2025-04-09 रोजी released, ने key agreement साठी mlkem768x25519-sha256 default केले.
• 10.1, 2025-10-06 रोजी released, ने connection मध्ये post-quantum half नसलेला key exchange negotiate झाल्यास client warning जोडली. हे ssh_config मधील WarnWeakCrypto option द्वारे नियंत्रित केले जाते आणि ते default ने enabled आहे.

लक्षात ठेवण्यासारखी तारीख April 2022 आहे. OpenSSH 9.0 किंवा त्यानंतरची आवृत्ती चालवणाऱ्या कोणत्याही दोन machines मध्ये तेव्हापासून post-quantum key exchange होत आहे. यासाठी कोणतेही configuration आवश्यक नाही आणि ssh टाइप करणाऱ्या व्यक्तीला याची कोणतीही सूचना दिली जात नाही.

कोणत्या Ubuntu release मध्ये ते समाविष्ट आहे

Ubuntu release वेळी OpenSSH ची आवृत्ती स्थिर करते आणि नंतर आवृत्ती क्रमांक न बदलता त्यात security fixes backport करते. त्यामुळे तुम्ही चालवत असलेली Ubuntu release तुमचा default algorithm ठरवते. कोणतीही यादी गृहीत न धरता, तुमच्यासमोरील machine वर ssh -V वापरून तपासा. August 2026 पर्यंत archive मध्ये या आवृत्त्या आहेत:

• 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 आहे आणि post-quantum नसलेल्या connections बद्दल ती warning देते.

दोन प्रत्यक्ष machines चे उदाहरण पाहू. 26.04 laptop 24.04 server शी connect होतो. Client ची पहिली निवड, mlkem768x25519-sha256, 9.6 server च्या यादीत नाही. Server कडे उपलब्ध असलेली client ची पुढील post-quantum निवड sntrup761x25519-sha512@openssh.com आहे आणि ssh -v हीच name दाखवते. कोणत्याही व्यक्तीने configuration न करता, 2024 मध्ये तयार केलेल्या server विरुद्ध key exchange post-quantum असतो.

22.04 चे प्रकरण उलटे आहे. ssh -Q kex एकट्याने दिशाभूल का करते हे यात स्पष्ट दिसते. OpenSSH 8.9 ला sntrup761x25519-sha512@openssh.com हे name माहीत आहे. त्यामुळे त्या box वर ssh -Q kex ते दाखवते. मात्र 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.

ही warning तुम्ही ज्या server शी connect होत आहात त्याबद्दल आहे; तुमच्या client बद्दल नाही. Server upgrade करणे हा उपाय आहे. WarnWeakCrypto no सेट केल्यास हा message नाहीसा होतो, पण connection मध्ये कोणताही बदल होत नाही.

हायब्रिड का, आणि harvest now, decrypt later म्हणजे काय

या धोक्याचे स्वरूप स्पष्ट आहे. तुमची network traffic पाहू शकणारा हल्लेखोर आज encrypted bytes नोंदवून साठवतो. तो त्या आज वाचू शकत नाही. X25519 तोडण्यासाठी पुरेसा मोठा quantum computer उपलब्ध होईपर्यंत तो त्या bytes जतन करतो आणि नंतर त्या वाचतो. याला harvest now, decrypt later किंवा store now, decrypt later म्हणतात. सध्या हल्लेखोराकडून कोणत्याही चतुर युक्तीची गरज नसते. त्याला disk space आणि संयम आवश्यक असतो.

ही समस्या encryption ला आहे; signatures ला नाही. ही विषमता पुढील सर्व निर्णय ठरवते. Encrypted ciphertext मधील data संवेदनशील असेपर्यंत नोंदवलेल्या ciphertext चे मूल्य टिकून राहते. Signature तपासली जात असताना ती forge करता येऊ नये, एवढीच आवश्यकता असते. 2035 मध्ये signature algorithm तोडता आल्यास कोणी 2035 मध्ये server ची बनावट ओळख निर्माण करू शकतो. परंतु त्यामुळे 2026 मधील login पूर्वीच्या काळात जाऊन forge करता येत नाही. त्यामुळे key exchange आधी सुरक्षित करणे आवश्यक होते; signature बाजूचे काम नंतर करता येते.

Hybrid म्हणजे दोन्ही algorithms चालतात आणि दोन्हींचे results session key तयार करण्यासाठी वापरले जातात. mlkem768x25519-sha256 मागील secret मिळवण्यासाठी हल्लेखोराला ML-KEM 768 आणि X25519 दोन्ही तोडावे लागतात. ही जोडी जाणीवपूर्वक निवडली आहे: ML-KEM हे X25519 पेक्षा बरेच नवीन आहे आणि cryptanalysts कडून त्याची तपासणी होण्यासाठी त्याला खूपच कमी काळ मिळाला आहे. त्यामुळे नवीन algorithm मध्ये आढळलेल्या त्रुटीमुळे तुम्हाला आधीपासून असलेले संरक्षण गमवावे लागत नाही.

काय संरक्षित आहे आणि काय संरक्षित नाही

Key exchange संरक्षित आहे. तुमचे session encrypt करणारा shared secret hybrid exchange मधून तयार झाला आहे. त्यामुळे आज नोंदवलेले ते session quantum computers उपलब्ध झाल्यानंतर वाचनीय होत नाही.

Host key संरक्षित नाही. debug1: kex: host key algorithm: ssh-ed25519 ओळीत classical signature नमूद आहे. rsa-sha2-512 आणि ECDSA (elliptic curve digital signature algorithm) प्रकारांसाठीही हेच लागू आहे. कार्यरत quantum computer असलेला attacker ही signature बनावट तयार करून तुमच्या serverची impersonation करू शकतो. मात्र हे केवळ त्या भविष्यातील वेळी सुरू असलेल्या live connectionदरम्यान शक्य असेल. आज नोंदवलेल्या trafficवर याचा परिणाम होणार नाही.

तुमची login key देखील संरक्षित नाही. ~/.ssh/id_ed25519 मधील key ही त्याच प्रकारची classical signature आहे. त्यामुळे हेच कारण लागू होते. या वर्षी त्या keyचे संरक्षण तिचे स्थान आणि ती वाचू शकणाऱ्या व्यक्तींवर अवलंबून आहे. म्हणून योग्य SSH key व्यवस्थापन या पृष्ठावरील कोणत्याही algorithm nameपेक्षा तुमचा वास्तविक धोका अधिक प्रभावीपणे कमी करते.

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

त्याच serverवरील TLS हा स्वतंत्र प्रश्न आहे आणि त्याचे उत्तरही स्वतंत्र आहे. TLS (transport layer security) हे तुमचा web server port 443 वर वापरतो. त्याचा codebase आणि release schedule वेगळा आहे. OpenSSH upgrade केल्याने त्यावर कोणताही परिणाम होत नाही. तुम्ही त्याच VPSवरील private serviceसाठी self-signed certificate वापरत असाल, तर त्याची signature आणि key exchange OpenSSL आणि तुमचा web server ठरवतात. त्यामुळे त्या stackचे स्वतंत्रपणे परीक्षण करा.

आता सुज्ञ ऑपरेटर काय करतो

OpenSSH अद्ययावत ठेवा आणि तेवढ्यावरच थांबा. या समस्येसाठी हीच संपूर्ण रणनीती आहे. sudo apt update && sudo apt upgrade मुळे तुमच्या Ubuntu release सोबत उपलब्ध होणारी आवृत्तीच वापरली जाते. नवीन OpenSSH मिळवण्यासाठी नवीन Ubuntu release वर जाणे आवश्यक आहे. unattended security upgrades सुरू केल्यास तुम्ही स्वतः लक्षात ठेवले नाही तरी ते patches लागू होतात. एखाद्या algorithm name मागे लागून OpenSSH source मधून build करणे हा योग्य तडजोडीचा पर्याय नाही. त्यामुळे सर्वाधिक exposed असलेल्या सेवेकरिता distribution कडून मिळणारे security updates गमावता. तरीही source मिळवणार असाल, तर build करण्यापूर्वी published checksum विरुद्ध download तपासा.

KexAlgorithms line स्वतः लिहू नका. ही एकच कृती परिस्थिती निश्चितपणे आणखी बिघडवते. 2018 मधील hardening guide तुम्हाला 2018 मध्ये योग्य असलेली यादी देते. ती sshd_config मध्ये paste केल्यास default list मध्ये भर पडत नाही; ती list पूर्णपणे बदलली जाते. त्यानंतर तयार झालेला प्रत्येक algorithm वगळला जातो. त्यामुळे server ने स्वतःहून mlkem768x25519-sha256 साठी negotiation केली असती, तरी pinned list मध्ये उरलेल्या पर्यायावर तो शांतपणे उतरतो. वारशाने मिळालेल्या कोणत्याही server वर sudo sshd -T | grep -i '^kexalgorithms' चालवा. त्याच release च्या fresh install वरील line पेक्षा ही line लहान असल्यास, कोणीतरी ती pinned केली आहे.

यादी बदलण्याचे खरे कारण असल्यास ती बदलण्याऐवजी त्यात भर घाला. OpenSSH सुरुवातीचा + append म्हणून, सुरुवातीचा - remove म्हणून आणि सुरुवातीचा ^ यादीच्या सुरुवातीला हलवणे म्हणून वाचतो.

KexAlgorithms ^mlkem768x25519-sha256

त्यावर अवलंबून राहण्यापूर्वी file तपासा. sudo sshd -t configuration parse करते. Configuration वैध असल्यास ती काहीही output करत नाही. Build मध्ये उपलब्ध नसलेल्या algorithm चे नाव असलेली KexAlgorithms line sshd सुरू होण्यापासून थांबवते. Remote box वर याचा अर्थ तुम्हाला पुन्हा प्रवेश करता येणार नाही. त्यामुळे काम करताना दुसरे session उघडे ठेवा. दोन्ही बाजूंच्या lists मध्ये समान पर्याय उरले नाहीत, तेव्हा 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" marketing कडे एका layer विषयी केलेला दावा म्हणून पाहा. एखादा vendor एखाद्या product ला quantum-safe म्हणत असेल, तर तो त्याने नमूद केलेल्या layer चे वर्णन करत असतो. ही layer सहसा कुठेतरी असलेली key exchange असते. Algorithm name आणि तो लागू होणारा protocol विचारा. August 2026 मधील OpenSSH साठी या दाव्याचे प्रामाणिक स्वरूप असे आहे की key exchange hybrid post-quantum आहे, तर signatures classical आहेत. यापेक्षा व्यापक दावा असल्यास त्यासोबत ssh -Q kex output मध्ये सापडेल असे नाव असले पाहिजे.

नेहमीची महत्त्वाची कामे करत राहा. Post-quantum key exchange मुळे अंदाज लावता येणाऱ्या password चे संरक्षण होत नाही. नंतर चोरीला जाणाऱ्या laptop वर copy केलेल्या private key चेही संरक्षण होत नाही. याच कारणांमुळे servers प्रत्यक्षात breach होतात. त्यामुळे VPS वरील standard SSH hardening अजूनही जवळजवळ संपूर्ण परिणाम घडवते. येथे दिलेले negotiation steps अपरिचित वाटत असल्यास, तुम्ही connect करता तेव्हा SSH काय करते या पृष्ठावर गृहीत धरलेल्या stages चे स्पष्टीकरण दिले आहे.

FAQ

माझे SSH कनेक्शन आधीच post-quantum आहे का?

`ssh -v yourserver 2>&1 | grep 'kex: algorithm' चालवा आणि त्यात छापलेले नाव वाचा. mlkem768x25519-sha256 आणि sntrup761x25519-sha512@openssh.com हे hybrid post-quantum exchanges आहेत. curve25519-sha256, ecdh-sha2-nistp256 आणि कोणतेही diffie-hellman-group` नाव classical आहेत. दोन्ही टोकांवर post-quantum नाव देणारी आवृत्ती असणे आवश्यक आहे. कारण negotiation मध्ये server देखील support करत असलेली client ची पहिली पसंती निवडली जाते. त्यामुळे जुनी machine उपलब्ध कमाल पर्याय ठरवते.

कोणत्या OpenSSH release मध्ये post-quantum key exchange default करण्यात आला?

2022-04-08 रोजी प्रसिद्ध झालेल्या OpenSSH 9.0 मध्ये `sntrup761x25519-sha512@openssh.com हे default key exchange करण्यात आले. 2024-09-19 रोजी प्रसिद्ध झालेल्या OpenSSH 9.9 मध्ये mlkem768x25519-sha256 जोडण्यात आले. 2025-04-09 रोजी प्रसिद्ध झालेल्या OpenSSH 10.0 मध्ये तेच default करण्यात आले. 2025-10-06 रोजी प्रसिद्ध झालेल्या OpenSSH 10.1 मध्ये connection पैकी कोणत्याही exchange मध्ये post-quantum पर्याय negotiate न झाल्यास warning दाखवण्यास सुरुवात झाली. तुमच्या Ubuntu release मध्ये यापैकी कोणते पर्याय उपलब्ध आहेत हे ठरते. त्यामुळे तुमच्या build चे वर्तन ssh -Q kex आणि ssh -G <host>` वापरून तपासा.

मी post-quantum SSH key तयार करावी का?

नाही. OpenSSH मध्ये असा key type नाही. आतापर्यंतचे post-quantum काम key exchange पर्यंत मर्यादित आहे. त्यासाठी तुमच्याकडून key files किंवा कोणतीही configuration आवश्यक नाही. Host keys आणि login keys अजूनही Ed25519 आणि RSA सारख्या classical signatures वापरतात. Upstream ने post-quantum signatures भविष्यातील release मध्ये उपलब्ध होतील असे सांगितले आहे. Ed25519 key वापरत राहा आणि ती जिथे साठवली आहे ते सुरक्षित ठेवा.

माझे connection post-quantum नाही असे ssh warning का दाखवते?

OpenSSH 10.1 आणि त्यानंतरच्या आवृत्त्या negotiated exchange मध्ये post-quantum भाग नसल्यास `** WARNING: connection is not using a post-quantum key exchange algorithm. छापतात. ही warning client बद्दल नसून server बद्दल आहे. तुमच्या client ने post-quantum नाव दिले होते, पण server ने त्यापैकी कोणतेही स्वीकारले नाही. Server चे OpenSSH upgrade करा किंवा त्याच्या sshd_config मध्ये कोणी आधुनिक नावे वगळणारी KexAlgorithms line निश्चित केली आहे का ते तपासा. WarnWeakCrypto no` सेट केल्याने message लपतो; मात्र connection पूर्वीइतकेच कमकुवत राहते.