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

پوسٹ کوانٹم SSH میں کیا بدلا ہے

زیادہ تر صارفین کے لیے post-quantum SSH پہلے ہی فعال ہے، اور کسی کو اسے configure کرنے کی ضرورت نہیں پڑی۔ موجودہ 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 اس کے بعد ہونے والی تمام communication کو encrypt کرتا ہے۔ تبدیلی key exchange میں ہوئی ہے۔ باقی کسی حصے میں تبدیلی نہیں ہوئی۔

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

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

سب سے پہلے دیکھیں کہ آپ کے 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 کرتی ہے، وہ ضروری نہیں کہ اسے پیش بھی کرے

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

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

ssh -G <host> اس host کے لیے client کی مؤثر configuration دکھاتا ہے، جب ~/.ssh/config اور /etc/ssh/ssh_config لاگو ہو چکے ہوں۔ sshd -T server کے لیے یہی کام کرتا ہے۔ ہر ایک preference order میں ایک single kexalgorithms line دکھاتا ہے، اور اس line میں پہلا نام اس side کی پہلی ترجیح ہوتا ہے۔ wire پر یہی 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 کبھی اسے طلب نہیں کرتا۔

اپنے کنکشن کے لیے طے شدہ الگورتھم پڑھیں

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

موجودہ client اور موجودہ server کے درمیان یہ کمانڈ درج ذیل نتیجہ دکھاتی ہے:

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 کے ساتھ اس کے بجائے آپ کو یہ نظر آ سکتا ہے:

debug1: kex: algorithm: curve25519-sha256

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

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

ssh -v کو صرف اس ایک line کے لیے جاننا کافی نہیں، کیونکہ یہی output اس وقت بھی کام آتا ہے جب login مکمل طور پر مسترد ہو اور آپ کو Permission denied (publickey) failure کی وجہ معلوم کرنی ہو۔

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

debug1: kex: host key algorithm: ssh-ed25519

کون سی OpenSSH ریلیز نے 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 ہوئی، نے اسے 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 میں پہلے والے طریقے کو 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 half موجود نہ ہو۔ یہ warning ssh_config میں موجود WarnWeakCrypto option سے control ہوتی ہے اور default طور پر enabled ہے۔

April 2022 یاد رکھنے کی اہم تاریخ ہے۔ 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 شامل ہے، جو mlkem768x25519-sha256 کو default بناتا ہے اور ان connections کے بارے میں warning دیتا ہے جو post-quantum نہیں ہیں۔

دو حقیقی machines کے درمیان یہ عمل دیکھیں۔ ایک 26.04 laptop، 24.04 server سے connect ہوتا ہے۔ Client کی پہلی ترجیح mlkem768x25519-sha256 ہے، لیکن یہ 9.6 server کی فہرست میں موجود نہیں۔ 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 اسے فہرست میں دکھاتا ہے، لیکن 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 کو صرف verification کے وقت ناقابل جعل سازی ہونا ضروری ہے۔ 2035 میں کسی signature algorithm کو توڑنے سے کوئی شخص 2035 میں server کی نقالی کر سکتا ہے۔ اس سے وہ 2026 میں کی گئی login کو واپس جا کر forge نہیں کر سکتا۔ اس لیے پہلے key exchange کو درست کرنا ضروری تھا، جبکہ signature کے حصے کو بعد کے لیے چھوڑا جا سکتا ہے۔

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

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

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

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 کی نقالی کر سکتا ہے، لیکن صرف اس مستقبل کے وقت live connection کے دوران، اور کبھی بھی آج record کیے گئے traffic کے خلاف نہیں۔

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

ان دونوں کے بارے میں آپ کو کچھ کرنے کی ضرورت نہیں، کیونکہ ابھی کسی متبادل پر منتقل ہونے کے لیے کچھ موجود نہیں ہے۔ OpenSSH نے کہا ہے کہ post-quantum signature support مستقبل کی release میں آ رہا ہے۔ جب تک یہ 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 ہے جس کا 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 کے ساتھ فراہم کردہ version پر برقرار رکھتا ہے، جبکہ نئے Ubuntu release پر منتقل ہونے سے نیا OpenSSH ملتا ہے۔ خودکار security upgrades فعال کرنے سے یہ patches آپ کی یاد دہانی کے بغیر لاگو ہو جاتے ہیں۔ کسی algorithm name کے پیچھے OpenSSH کو source سے build کرنا ناقص فیصلہ ہے، کیونکہ اس سے سرور کی سب سے زیادہ exposed service کے لیے distribution کے security updates ختم ہو جاتے ہیں۔ اگر پھر بھی source حاصل کریں تو build کرنے سے پہلے download کو اس کے published checksum سے verify کریں۔

خود سے KexAlgorithms line نہ لکھیں۔ یہ وہ واحد اقدام ہے جو قابلِ اعتماد طور پر صورتِ حال خراب کرتا ہے۔ 2018 کی hardening guide آپ کو ایسی فہرست دیتی ہے جو 2018 میں درست تھی، اور اسے sshd_config میں paste کرنے سے default فہرست میں اضافہ نہیں ہوتا بلکہ وہ replace ہو جاتی ہے۔ اس کے بعد بننے والا ہر algorithm خارج ہو جاتا ہے، اس لیے جو server خود mlkem768x25519-sha256 پر negotiation کر سکتا تھا، وہ خاموشی سے pinned فہرست میں باقی رہ جانے والی کسی بھی چیز پر آ جاتا ہے۔ جس 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 نہیں کرتا۔ کسی ایسے algorithm کا نام دینے والی KexAlgorithms line جسے build support نہیں کرتا، sshd کو start ہونے سے روک دیتی ہے۔ remote box پر اس کا مطلب ہے کہ آپ دوبارہ login نہیں کر سکیں گے، اس لیے کام کے دوران دوسری session کھلی رکھیں۔ جب دونوں sides کی فہرستوں میں کوئی مشترک algorithm باقی نہ رہے تو 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 ہیں۔ اس سے وسیع تر کوئی بھی دعویٰ ایسی name کے ساتھ آنا چاہیے جسے آپ ssh -Q kex output میں تلاش کر سکیں۔

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

FAQ

کیا میرا SSH connection پہلے ہی 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 کو 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 نے اس وقت warning دینا شروع کی جب connection میں دونوں میں سے کوئی بھی negotiate نہ ہو۔ اپنے build کا رویہ ssh -Q kex اور ssh -G <host>` سے check کریں، کیونکہ آپ کی Ubuntu release طے کرتی ہے کہ ان میں سے کون سا دستیاب ہے۔

کیا مجھے post-quantum SSH key بنانی چاہیے؟

نہیں، کیونکہ OpenSSH میں ایسی key type موجود نہیں ہے۔ اب تک post-quantum کام key exchange تک محدود ہے۔ اس کے لیے آپ کی کسی key file یا کسی configuration کی ضرورت نہیں ہوتی۔ Host keys اور login keys اب بھی classical signatures ہیں، جیسے Ed25519 اور RSA۔ 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. اس وقت print کرتے ہیں جب negotiated exchange میں post-quantum حصہ موجود نہ ہو۔ warning server کے بارے میں ہے، client کے بارے میں نہیں، کیونکہ آپ کے client نے post-quantum نام پیش کیا تھا لیکن server نے ان میں سے کوئی بھی قبول نہیں کیا۔ Server کی OpenSSH upgrade کریں، یا check کریں کہ کسی نے اس کے sshd_config میں KexAlgorithms line pin تو نہیں کی جو جدید ناموں کو خارج کرتی ہو۔ WarnWeakCrypto no` set کرنے سے message چھپ جاتا ہے، لیکن connection بالکل اسی طرح کمزور رہتا ہے۔