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) हा server मध्ये login करण्यासाठी वापरला जाणारा protocol आहे. 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 चे effective configuration दाखवते. sshd -T server साठी हेच कार्य करते. प्रत्येक command preference order नुसार एकच kexalgorithms line दाखवते. त्या line मधील पहिले नाव त्या बाजूची पहिली पसंती असते. Network वर पाठवले जाणारे configuration म्हणजे हीच line.

हे अंतर केवळ सैद्धांतिक नाही. 2021-03-03 रोजी released झालेल्या 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 शी कनेक्ट केल्यास त्याऐवजी पुढील output दिसू शकतो:

debug1: kex: algorithm: curve25519-sha256

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

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

grep आणि ssh -v काढल्यास negotiation मधील उर्वरित भाग दिसतो. त्यामध्ये पुढील section ज्या ओळीबद्दल आहे ती ओळही समाविष्ट आहे:

debug1: kex: host key algorithm: ssh-ed25519

हायब्रिड exchange कोणत्या OpenSSH release मध्ये 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 ही सामान्य पद्धत झाली.
• 9.9, 2024-09-19 रोजी released, ने दुसरा पर्याय म्हणून mlkem768x25519-sha256 जोडले. याच release मध्ये जुन्या method ला IANA registered name sntrup761x25519-sha512 देण्यात आले. त्यामुळे नवीन builds मध्ये ते दोन्ही spellings अंतर्गत दिसते.
• 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 चे negotiation करते.
• 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 मध्ये हेच नाव दिसते. 2024 मध्ये तयार केलेल्या server विरुद्ध key exchange post-quantum राहते. यासाठी कोणत्याही व्यक्तीने कोणतेही configuration केलेले नसते.

22.04 चे प्रकरण उलट आहे. ssh -Q kex मुळे एकट्याने दिशाभूल का होऊ शकते हे यात स्पष्ट दिसते. OpenSSH 8.9 ला sntrup761x25519-sha512@openssh.com हे नाव माहीत आहे. त्यामुळे त्या machine वर 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 नोंदवून ठेवतो. तो त्या bytes चे वाचन आज करू शकत नाही. X25519 तोडण्यासाठी पुरेसा मोठा quantum computer उपलब्ध होईपर्यंत तो त्या bytes जतन करून ठेवतो आणि नंतर त्यांचे वाचन करतो. याला harvest now, decrypt later किंवा store now, decrypt later म्हणतात. सध्याच्या काळात हल्लेखोराकडून कोणत्याही विशेष कौशल्याची आवश्यकता नसते. त्याला disk space आणि संयम आवश्यक असतो.

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

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

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

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

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

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

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

त्याच server वरील TLS हा स्वतंत्र प्रश्न आहे आणि त्याचे उत्तरही स्वतंत्र आहे. TLS (transport layer security) हे तुमचा web server port 443 वर वापरतो. त्याचा codebase आणि release schedule वेगळा आहे. OpenSSH upgrade केल्याने TLS मध्ये कोणताही बदल होत नाही. तुम्ही त्याच 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 वर upgrade करणे आवश्यक आहे. unattended security upgrades सुरू केल्यास तुम्ही स्वतः लक्षात ठेवले नाही तरी ते patches लागू होतात. एखाद्या algorithm नावामागे लागून OpenSSH source मधून build करणे योग्य तडजोड नाही. कारण सर्वाधिक उघड असलेल्या सेवेसाठी distribution कडून मिळणारे security updates तुम्ही गमावता. तरीही source fetch करत असाल, build करण्यापूर्वी download ची प्रकाशित checksum शी पडताळणी करा.

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

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

KexAlgorithms ^mlkem768x25519-sha256

Configuration वर अवलंबून राहण्यापूर्वी file तपासा. sudo sshd -t configuration parse करते आणि ती वैध असल्यास काहीही print करत नाही. 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 म्हणत असल्यास, तो vendor ज्या layer चे नाव घेतो त्याचे वर्णन करत असतो. ती layer सहसा कुठेतरी असलेली key exchange असते. Algorithm चे नाव आणि तो लागू होणारा 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 प्रत्यक्षात ताब्यात घेतले जातात. त्यामुळे 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 ला देखील समर्थित असलेली client ची पहिली पसंती निवडली जाते. त्यामुळे जुने machine उपलब्ध पर्यायांची कमाल मर्यादा ठरवते.

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

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

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

नाही, कारण 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 वापरत राहा आणि ती जिथे stored आहे त्या ठिकाणाचे संरक्षण करा.

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

OpenSSH 10.1 आणि त्यानंतरच्या आवृत्त्या negotiated exchange मध्ये post-quantum half नसल्यास `** 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 कोणी pin केलेली नाही ना, ते तपासा. WarnWeakCrypto no` सेट केल्याने message लपतो; connection जसे पूर्वी weak होते तसेच राहते.