Ubuntu پر Post-Quantum SSH میں کیا بدلا؟

Post-quantum SSH میں کیا تبدیل ہوا

زیادہ تر صارفین کے لیے post-quantum SSH پہلے ہی فعال ہے، اور انہیں کوئی configuration نہیں کرنی پڑی۔ موجودہ OpenSSH client جب موجودہ OpenSSH server سے رابطہ کرتا ہے تو default طور پر hybrid post-quantum key exchange منتخب کرتا ہے۔ اس طرح session key ایسے attacker کے خلاف مزاحمت کرتی ہے جو آج آپ کا network traffic record کرے اور کئی سال بعد اسے decrypt کرے۔ یہ تحفظ حقیقی ہے، لیکن "quantum-safe SSH" کی اصطلاح جتنا وسیع مفہوم ظاہر کرتی ہے، تحفظ اس سے محدود ہے۔

پہلے دو اصطلاحات سمجھ لیں۔ SSH (secure shell) وہ protocol ہے جس کے ذریعے آپ server میں login کرتے ہیں۔ key exchange، جسے عموماً "kex" لکھا جاتا ہے، ہر SSH connection کا پہلا مرحلہ ہے۔ دونوں سروں کے درمیان shared secret طے ہوتا ہے، اور اس secret سے اس کے بعد ہونے والی تمام ترسیل encrypt ہوتی ہے۔ تبدیلی key exchange میں ہوئی ہے۔ باقی کسی حصے میں تبدیلی نہیں ہوئی۔

اس صفحے پر اعتماد نہ کریں، کمانڈز خود چلائیں

ذیل میں دیے گئے ہر algorithm کا نام ایسی کمانڈ سے حاصل ہوتا ہے جسے آپ خود چلا سکتے ہیں۔ یہ جان بوجھ کر ایسا رکھا گیا ہے۔ ہر OpenSSH release کے ساتھ default تبدیل ہوتا رہتا ہے، اس لیے دو سال پہلے لکھی گئی guide میں ایسا algorithm درج ہو سکتا ہے جسے آپ کی machine اب ترجیح نہیں دیتی، اور وہ guide آپ کو یہ نہیں بتا سکتی۔ یہ کمانڈز سیکھ لیں، پھر آپ کو اس موضوع پر مضامین کی ضرورت نہیں رہے گی، اس مضمون کی بھی نہیں۔

سب سے پہلے معلوم کریں کہ آپ کی build کیا کچھ کر سکتی ہے۔

ssh -V
ssh -Q kex

ssh -V ایک version line پرنٹ کرتا ہے جو OpenSSH_ سے شروع ہوتی ہے، اس کے بعد 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 میں موجود support، پیش کردہ options کے برابر نہیں ہوتا

یہ وہ فرق ہے جسے زیادہ تر تحریریں نظر انداز کر دیتی ہیں۔ ssh -Q kex ایک سوال کا جواب دیتا ہے: یہ binary کیا کر سکتی ہے؟ یہ اس سوال کا جواب نہیں دیتا جو آپ کے لیے اہم ہے: یہ connection حقیقت میں کیا propose کرے گا؟ دونوں lists مختلف ہیں، اور ان کے درمیان موجود فرق ہی وہ جگہ ہے جہاں پرانا مشورہ حقیقی نقصان پہنچاتا ہے۔

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 میں پہلا نام اسی side کی پہلی ترجیح ہوتا ہے۔ network پر بھیجی جانے والی چیز یہی line ہوتی ہے۔

یہ فرق محض نظری نہیں ہے۔ 2021-03-03 کو جاری ہونے والے OpenSSH 8.5 میں sntrup761x25519-sha512@openssh.com شامل کیا گیا، لیکن اسے default list سے جان بوجھ کر خارج رکھا گیا۔ اس release میں ssh -Q kex algorithm دکھاتا ہے، جبکہ ssh -G اسے نہیں دکھاتا۔ اس کا مطلب ہے کہ binary post-quantum key exchange کر سکتی ہے، لیکن کوئی بھی connection اسے استعمال کرنے کی درخواست نہیں کرتا۔

اپنے connection کے لیے negotiated 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 کے طور پر standardise کیا گیا ہے) چلاتا ہے، اسے X25519 elliptic curve Diffie-Hellman کے ساتھ استعمال کرتا ہے، اور دونوں outputs کو session key میں شامل کرتا ہے۔

پرانے server کے ساتھ اس کے بجائے یہ output آ سکتا ہے:

debug1: kex: algorithm: curve25519-sha256

اس نام میں post-quantum حصہ شامل نہیں ہے۔ curve25519-sha256 صرف elliptic curve Diffie-Hellman ہے، اور بڑا quantum computer اسے توڑ سکتا ہے۔ default تبدیل کرنے کی یہی بنیادی وجہ ہے۔

ایک negotiation rule واضح کرتا ہے کہ ایک پرانی machine session کو کیوں محدود کر دیتی ہے۔ client اپنی فہرست ترجیحی ترتیب میں بھیجتا ہے، server اپنی فہرست بھیجتا ہے، اور منتخب کیا جانے والا algorithm client کی فہرست میں موجود وہ پہلا نام ہوتا ہے جو server کی فہرست میں بھی شامل ہو۔ client کی ترجیح غالب رہتی ہے، اس لیے دونوں endpoints میں سے پرانا endpoint طے کرتا ہے کہ فہرست میں آپ کتنی دور تک جا سکتے ہیں۔ اپنے laptop کو upgrade کرنے سے ایسے server کے ساتھ session upgrade نہیں ہوتا جس نے ML-KEM کے بارے میں کبھی نہیں سنا۔

grep اور ssh -v کو drop کریں تو negotiation کا باقی حصہ دکھائی دیتا ہے، جس میں وہ line بھی شامل ہے جس کے بارے میں اگلا section ہے:

debug1: kex: host key algorithm: ssh-ed25519

کس OpenSSH release نے hybrid exchange کو default بنایا

Upstream release notes ایک واضح ترتیب فراہم کرتی ہیں۔ Version numbers کے مقابلے میں dates زیادہ اہم ہیں، کیونکہ ان سے معلوم ہوتا ہے کہ یہ عمل کتنے عرصے سے خاموشی سے جاری ہے۔

• 8.5، جو 2021-03-03 کو release ہوا، اس میں sntrup761x25519-sha512@openssh.com شامل کیا گیا، لیکن اسے default طور پر disabled رکھا گیا۔
• 9.0، جو 2022-04-08 کو release ہوا، نے اسے enabled کر دیا۔ Notes میں لکھا ہے کہ OpenSSH "use the hybrid Streamlined NTRU Prime + x25519 key exchange method by default" کرے گا۔ یہی وہ release ہے جس میں post-quantum key exchange معمول کا طریقہ بنا۔
• 9.9، جو 2024-09-19 کو release ہوا، اس میں دوسرے option کے طور پر mlkem768x25519-sha256 شامل کیا گیا۔ اسی release میں پہلے والے method کو IANA registered name sntrup761x25519-sha512 دیا گیا، اس لیے نئے builds میں یہ دونوں ناموں سے درج ہوتا ہے۔
• 10.0، جو 2025-04-09 کو release ہوا، نے key agreement کے لیے mlkem768x25519-sha256 کو default بنا دیا۔
• 10.1، جو 2025-10-06 کو release ہوا، نے اس وقت client warning شامل کی جب connection ایسے key exchange پر negotiate ہو جس میں post-quantum حصہ موجود نہ ہو۔ اسے ssh_config میں موجود WarnWeakCrypto option control کرتا ہے، اور یہ default طور پر enabled ہے۔

April 2022 وہ date ہے جسے یاد رکھنا چاہیے۔ OpenSSH 9.0 یا اس کے بعد کا version چلانے والی مشینوں کی ہر جوڑی اس وقت سے post-quantum key exchange استعمال کر رہی ہے، بغیر کسی configuration اور ssh ٹائپ کرنے والے شخص کو کسی اطلاع کے۔

یہ کس Ubuntu ریلیز میں شامل ہے

Ubuntu ریلیز کے وقت OpenSSH کا ایک ورژن مقرر کرتا ہے، پھر ورژن نمبر تبدیل کیے بغیر اس میں security fixes backport کرتا ہے۔ اس لیے آپ جو Ubuntu ریلیز چلا رہے ہیں، وہ آپ کے default algorithm کا تعین کرتی ہے۔ فہرست پر انحصار کرنے کے بجائے سامنے موجود machine کو ssh -V سے check کریں۔ August 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 کے بارے میں warning دیتا ہے جو post-quantum نہیں ہیں۔

دو حقیقی machines کے درمیان یہ عمل دیکھیں۔ 26.04 laptop، 24.04 server سے connect ہوتا ہے۔ Client کی پہلی ترجیح، mlkem768x25519-sha256، 9.6 server کی list میں موجود نہیں ہے۔ Client کی اگلی post-quantum ترجیح جو server کے پاس موجود ہے، sntrup761x25519-sha512@openssh.com ہے، اور ssh -v اسی نام کی رپورٹ کرتا ہے۔ Key exchange کے لحاظ سے session post-quantum ہے، حالانکہ server 2024 میں بنایا گیا تھا اور کسی نے بھی کوئی configuration تبدیل نہیں کی۔

22.04 کا معاملہ اس کے برعکس ہے، اور یہ واضح کرتا ہے کہ صرف ssh -Q kex گمراہ کن کیوں ہے۔ OpenSSH 8.9، sntrup761x25519-sha512@openssh.com نام کو جانتا ہے، اس لیے اس machine پر 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.

یہ warning اس server کے بارے میں ہے جس سے آپ connect ہو رہے ہیں، آپ کے client کے بارے میں نہیں۔ حل یہ ہے کہ server کو upgrade کریں۔ WarnWeakCrypto no مقرر کرنے سے message ختم ہو جاتا ہے، لیکن connection میں کوئی تبدیلی نہیں آتی۔

ہائبرڈ کیوں، اور harvest now decrypt later کا مطلب کیا ہے

اس خطرے کی نوعیت سادہ ہے۔ جو حملہ آور آپ کے network traffic کو دیکھ سکتا ہے، وہ آج encrypted bytes ریکارڈ کرکے محفوظ کر لیتا ہے۔ وہ انہیں آج نہیں پڑھ سکتا۔ وہ اس وقت تک انتظار کرتا ہے جب تک X25519 کو توڑنے کے لیے کافی بڑا quantum computer دستیاب نہ ہو جائے، پھر انہیں پڑھ لیتا ہے۔ اسے harvest now, decrypt later یا store now, decrypt later کہا جاتا ہے۔ اس کے لیے موجودہ وقت میں حملہ آور کو کسی پیچیدہ طریقے کی ضرورت نہیں ہوتی۔ اسے صرف disk space اور صبر درکار ہوتا ہے۔

یہ مسئلہ encryption کو درپیش ہے، signatures کو نہیں، اور یہی عدم توازن باقی تمام فیصلوں کی بنیاد بنتا ہے۔ Recorded ciphertext اپنی قدر اس وقت تک برقرار رکھتا ہے جب تک اس میں موجود data حساس رہتا ہے۔ کسی signature کو صرف اس وقت ناقابلِ جعل سازی ہونا ضروری ہے جب اس کی جانچ کی جائے۔ 2035 میں کسی signature algorithm کو توڑنے سے کوئی شخص 2035 میں کسی server کی نقالی کر سکتا ہے۔ اس سے وہ 2026 کے login کو واپس جا کر forge نہیں کر سکتا۔ اس لیے پہلے key exchange کو محفوظ بنانا ضروری تھا، جبکہ signature والا حصہ بعد میں کیا جا سکتا ہے۔

Hybrid کا مطلب ہے کہ دونوں algorithms چلیں اور دونوں کے نتائج session key بنانے میں شامل ہوں۔ mlkem768x25519-sha256 کے پیچھے موجود secret حاصل کرنے کے لیے حملہ آور کو ML-KEM 768 اور X25519، دونوں کو توڑنا ہوگا۔ یہ جوڑا جان بوجھ کر منتخب کیا گیا ہے: ML-KEM، X25519 کے مقابلے میں بہت نیا ہے اور cryptanalysts کے حملوں کا اسے بہت کم عرصے سے سامنا ہے۔ اس لیے نئے algorithm میں ملنے والی خامی سے وہ تحفظ ختم نہیں ہوتا جو آپ کو پہلے سے حاصل تھا۔

جو محفوظ ہے اور جو محفوظ نہیں

کلیدی تبادلہ محفوظ ہے۔ آپ کے session کو encrypt کرنے والا shared secret ایک hybrid exchange سے حاصل ہوا تھا، اس لیے آج اس session کی recording بعد میں quantum computers آنے پر readable نہیں ہو جائے گی۔

host key محفوظ نہیں ہے۔ debug1: kex: host key algorithm: ssh-ed25519 لائن ایک classical signature کو ظاہر کرتی ہے، اور rsa-sha2-512 اور ECDSA (elliptic curve digital signature algorithm) types بھی اسی طرح ہیں۔ کسی attacker کے پاس کام کرنے والا quantum computer ہو تو وہ اس signature کو forge کر کے آپ کے server کی نقالی کر سکتا ہے، لیکن صرف اس مستقبل کے وقت live connection کے دوران، اور آج record کیے گئے traffic کے خلاف کبھی نہیں۔

آپ کی login key بھی محفوظ نہیں ہے۔ ~/.ssh/id_ed25519 میں موجود key بھی اسی قسم کی classical signature ہے، اور یہی منطق اس پر بھی لاگو ہوتی ہے۔ اس سال اس key کو جو چیز محفوظ رکھتی ہے وہ یہ ہے کہ وہ کہاں موجود ہے اور اسے کون پڑھ سکتا ہے۔ اس لیے مناسب SSH key management آپ کے حقیقی risk کو اس صفحے پر موجود کسی بھی algorithm name سے کہیں زیادہ کم کرتا ہے۔

ان دونوں کے بارے میں آپ کو کچھ کرنے کی ضرورت نہیں، کیونکہ ابھی کسی متبادل پر منتقل ہونے کے لیے کچھ موجود نہیں۔ OpenSSH نے کہا ہے کہ post-quantum signature support مستقبل کی release میں آئے گا۔ اس کے دستیاب ہونے تک OpenSSH میں post-quantum host key type اور post-quantum user key type موجود نہیں ہیں، اور ssh-keygen بھی ایسا کوئی type فراہم نہیں کرتا۔ جو guide آپ کو ایسی key generate کرنے کا کہتی ہے، وہ ایسے software کی وضاحت کر رہی ہے جو ابھی موجود نہیں۔

اسی server پر TLS ایک الگ سوال ہے اور اس کا جواب بھی الگ ہے۔ TLS (transport layer security) وہ protocol ہے جس سے آپ کا 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 آپ کو اسی version پر رکھتا ہے جو آپ کی Ubuntu release کے ساتھ فراہم ہوتا ہے، جبکہ نئی Ubuntu release پر منتقل ہونے سے آپ نئے OpenSSH پر منتقل ہوتے ہیں۔ غیر زیرِ نگرانی security upgrades فعال کرنے سے یہ patches خودکار طور پر لاگو ہو جاتے ہیں اور آپ کو انہیں یاد رکھنے کی ضرورت نہیں رہتی۔ کسی algorithm name کے پیچھے OpenSSH کو source سے build کرنا ناقص فیصلہ ہے، کیونکہ اس سے server کی سب سے زیادہ exposed service کے لیے distribution کے security updates ختم ہو جاتے ہیں۔ اگر آپ پھر بھی source حاصل کریں تو build سے پہلے download کو اس کے شائع کردہ checksum سے verify کریں۔

خود سے KexAlgorithms کی line نہ لکھیں۔ یہ وہ واحد اقدام ہے جو قابلِ اعتماد طور پر صورتِ حال کو خراب کرتا ہے۔ 2018 کی hardening guide آپ کو ایسی فہرست دیتی ہے جو 2018 میں درست تھی، اور اسے sshd_config میں paste کرنے سے default فہرست میں اضافہ نہیں ہوتا بلکہ وہ replace ہو جاتی ہے۔ اس کے بعد ایجاد ہونے والا ہر algorithm خارج ہو جاتا ہے، اس لیے جو server خود mlkem768x25519-sha256 پر negotiation کر سکتا تھا، وہ خاموشی سے pinned فہرست میں باقی رہ جانے والے option پر آ جاتا ہے۔ اپنے زیرِ انتظام ملنے والے ہر server پر sudo sshd -T | grep -i '^kexalgorithms' چلائیں۔ اگر یہ line اسی release کی fresh install میں موجود line سے مختصر ہے تو کسی نے اسے pin کیا ہے۔

اگر فہرست تبدیل کرنے کی حقیقی وجہ ہو تو اسے replace کرنے کے بجائے اس میں اضافہ کریں۔ OpenSSH ابتدائی + کو append، ابتدائی - کو remove، اور ابتدائی ^ کو فہرست کے آغاز میں منتقل کرنے کے طور پر پڑھتا ہے۔

KexAlgorithms ^mlkem768x25519-sha256

اس پر بھروسا کرنے سے پہلے file کو test کریں۔ sudo sshd -t configuration کو parse کرتا ہے اور valid ہونے کی صورت میں کچھ print نہیں کرتا۔ اگر KexAlgorithms line میں ایسا algorithm نامزد ہو جو build میں موجود نہ ہو تو sshd start نہیں ہوتا۔ Remote box پر اس کا مطلب ہے کہ آپ دوبارہ اندر داخل نہیں ہو سکتے، اس لیے کام کرتے وقت دوسری session کھلی رکھیں۔ جب دونوں اطراف کی فہرستوں میں کوئی مشترک option باقی نہ رہے تو 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 کا نام اور وہ protocol پوچھیں جس پر یہ لاگو ہوتا ہے۔ August 2026 میں OpenSSH کے بارے میں اس دعوے کا دیانت دارانہ بیان یہ ہے کہ key exchange hybrid post-quantum ہے، جبکہ signatures classical ہیں۔ اس سے وسیع تر ہر دعوے کے ساتھ ایسا نام ہونا چاہیے جو آپ ssh -Q kex کے output میں تلاش کر سکیں۔

بورنگ لیکن ضروری کام جاری رکھیں۔ Post-quantum key exchange کسی قابلِ قیاس password کے مسئلے کو حل نہیں کرتا، نہ ہی ایسے private key کا جسے laptop پر copy کیا گیا ہو اور وہ بعد میں چوری ہو جائے۔ Servers پر حقیقی حملوں کی وجہ یہی چیزیں بنتی ہیں، اور VPS پر standard SSH hardening اب بھی تقریباً سارا حفاظتی بوجھ اٹھاتی ہے۔ اگر یہاں بیان کردہ negotiation کے مراحل آپ کے لیے نئے تھے تو connect کرتے وقت SSH کیا کرتا ہے ان مراحل کی وضاحت کرتا ہے جنہیں یہ صفحہ آپ کے علم میں شامل سمجھتا ہے۔

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 نام رکھنے والے دیگر تمام exchanges classical ہیں۔ دونوں سروں پر ایسا version ہونا چاہیے جو post-quantum نام پیش کرتا ہو، کیونکہ negotiation میں client کی پہلی ایسی choice منتخب ہوتی ہے جسے server بھی support کرتا ہو۔ اس لیے پرانی 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 نے اس وقت warning دینا شروع کی جب connection میں دونوں میں سے کوئی بھی negotiate نہ ہو۔ اپنے build کا رویہ ssh -Q kex اور ssh -G <host> سے جانچیں، کیونکہ آپ کا Ubuntu release طے کرتا ہے کہ ان میں سے کون سے options دستیاب ہیں۔

کیا مجھے 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 استعمال کرتے رہیں اور جہاں یہ محفوظ ہے اس جگہ کی حفاظت کریں۔

ssh یہ warning کیوں دیتا ہے کہ میرا connection post-quantum نہیں ہے؟

OpenSSH 10.1 اور اس کے بعد کے versions ** WARNING: connection is not using a post-quantum key exchange algorithm. اس وقت دکھاتے ہیں جب negotiated exchange میں post-quantum حصہ موجود نہ ہو۔ یہ warning server کے بارے میں ہے، client کے بارے میں نہیں، کیونکہ آپ کے client نے post-quantum نام پیش کیا تھا اور server نے ان میں سے کوئی بھی قبول نہیں کیا۔ Server کا OpenSSH upgrade کریں، یا جانچیں کہ کسی نے اس کی sshd_config میں KexAlgorithms line pin کر کے جدید نام خارج تو نہیں کیے۔ WarnWeakCrypto no setting پیغام چھپا دیتی ہے، لیکن connection کو بالکل اسی طرح کمزور چھوڑ دیتی ہے جیسے وہ پہلے تھا۔