Ubuntu-তে Post-Quantum SSH: কী বদলেছে

Post-quantum SSH-এ কী পরিবর্তন হয়েছে

বেশিরভাগ ব্যবহারকারীর জন্য post-quantum SSH ইতিমধ্যেই চালু আছে, এবং এটি configure করার প্রয়োজন হয়নি। বর্তমান OpenSSH client যখন বর্তমান OpenSSH server-এর সঙ্গে সংযোগ করে, তখন default হিসেবে hybrid post-quantum key exchange নির্বাচন করে। ফলে কোনো attacker আজ আপনার network traffic record করে কয়েক বছর পরে decrypt করার চেষ্টা করলেও session key প্রতিরোধী থাকে। এই সুরক্ষা বাস্তব, তবে "quantum-safe SSH" কথাটি যে ব্যাপক অর্থ বোঝায়, এর পরিধি তার চেয়ে সীমিত।

প্রথমে দুটি term জেনে নিন। SSH (secure shell) হলো সেই protocol, যার মাধ্যমে আপনি server-এ login করেন। Key exchange, সাধারণত "kex" নামে লেখা হয়, প্রতিটি SSH connection-এর প্রথম ধাপ। দুই প্রান্ত একটি shared secret-এ সম্মত হয়, এবং পরবর্তী সবকিছু encrypt করতে সেই secret ব্যবহার করা হয়। পরিবর্তনটি key exchange অংশে হয়েছে। অন্য কোনো অংশে পরিবর্তন হয়নি।

এই পৃষ্ঠাটি বিশ্বাস করবেন না, নিজে কমান্ড চালান

নিচে দেওয়া প্রতিটি algorithm-এর নাম আপনি নিজে চালিয়ে পরীক্ষা করতে পারেন এমন একটি command থেকে নেওয়া। এটি ইচ্ছাকৃত। প্রতিটি OpenSSH release-এর সঙ্গে default পরিবর্তিত হয়। তাই দুই বছর আগে লেখা কোনো গাইডে এমন algorithm-এর নাম থাকতে পারে, যেটিকে আপনার machine আর preferred algorithm হিসেবে ব্যবহার করে না। সেই গাইড নিজে থেকে এটি জানাতে পারে না। এই command-গুলো শিখে নিলে এ বিষয়ে লেখা কোনো article-এর, এমনকি এই article-এরও, আর প্রয়োজন হবে না।

আপনার 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-এর মতো 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-এর জন্য একই কাজ করে। প্রতিটি preference order-এ একটি মাত্র kexalgorithms line দেখায়, এবং ওই line-এর প্রথম name হলো সেই পক্ষের প্রথম পছন্দ। Wire-এ পাঠানো হয় এই 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-এর মধ্যে এটি চালালে ফলাফল হবে:

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 কার্যকর হয়। তাই দুই প্রান্তের মধ্যে পুরোনো প্রান্তটি ঠিক করে দেয় তালিকায় কত দূর পর্যন্ত এগোনো যাবে। আপনার laptop upgrade করলেও এমন server-এর সঙ্গে session upgrade হবে না, যে ML-KEM সম্পর্কে কখনও জানেনি।

ssh -v শুধু এই একটি line-এর জন্য নয়, আরও অনেক কারণে জানা দরকার। Login সরাসরি প্রত্যাখ্যাত হলে একই output-এ আপনি Permission denied (publickey) ত্রুটি অনুসন্ধান করতে পারেন।

grep এবং ssh -v বাদ দিলে negotiation-এর বাকি অংশ দেখা যাবে। এর মধ্যে পরের section-এ আলোচিত line-টিও থাকবে:

debug1: kex: host key algorithm: ssh-ed25519

কোন OpenSSH release hybrid exchange-কে default করেছিল

Upstream release notes-এ ধারাবাহিকতাটি স্পষ্ট। Version number-এর চেয়ে তারিখ বেশি গুরুত্বপূর্ণ, কারণ এতে বোঝা যায় এই ব্যবস্থা কত দিন ধরে নীরবে চালু আছে।

• 8.5, 2021-03-03-এ released, sntrup761x25519-sha512@openssh.com যোগ করেছিল এবং এটি default অবস্থায় disabled রেখেছিল।
• 9.0, 2022-04-08-এ released, এটি enabled করে। Notes-এ বলা হয়েছে, OpenSSH “use the hybrid Streamlined NTRU Prime + x25519 key exchange method by default” করবে। এই release থেকেই post-quantum key exchange স্বাভাবিক default হয়ে যায়।
• 9.9, 2024-09-19-এ released, দ্বিতীয় option হিসেবে mlkem768x25519-sha256 যোগ করেছিল। একই release-এ পুরোনো method-টির IANA registered name sntrup761x25519-sha512 নির্ধারণ করা হয়। তাই newer build-গুলোতে এটি উভয় spelling-এ দেখা যায়।
• 10.0, 2025-04-09-এ released, key agreement-এর জন্য mlkem768x25519-sha256-কে default করে।
• 10.1, 2025-10-06-এ released, এমন key exchange negotiate হলে client warning যোগ করে যেখানে post-quantum half নেই। এটি ssh_config-এর WarnWeakCrypto option দ্বারা নিয়ন্ত্রিত এবং default অবস্থায় enabled।

April 2022 তারিখটি মনে রাখা গুরুত্বপূর্ণ। OpenSSH 9.0 বা newer চালানো যেকোনো দুইটি machine তখন থেকে post-quantum key exchange ব্যবহার করে আসছে। এর জন্য কোনো configuration প্রয়োজন হয়নি এবং ssh টাইপ করা ব্যক্তিকে কোনো announcement দেখানো হয়নি।

কোন Ubuntu release এটি সরবরাহ করে

Ubuntu কোনো release-এর সময় OpenSSH-এর একটি version নির্দিষ্ট করে, তারপর version number পরিবর্তন না করে তাতে security fix backport করে। তাই আপনি যে Ubuntu release চালাচ্ছেন, সেটিই আপনার default algorithm নির্ধারণ করে। কোনো তালিকার ওপর নির্ভর না করে ssh -V দিয়ে সামনের মেশিনটি পরীক্ষা করুন। August 2026 অনুযায়ী archive-এ এই version-গুলো রয়েছে:

• 22.04 LTS-এ 1:8.9p1 রয়েছে। এটি 9.0-এর default-এর আগের version, তাই stock install curve25519-sha256 negotiate করে।
• 24.04 LTS-এ 1:9.6p1 রয়েছে। এটি 9.0-এর পরের এবং 9.9-এর আগের version, তাই এর 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 নয় এমন connection সম্পর্কে warning দেয়।

দুটি বাস্তব মেশিনের জোড়া দিয়ে বিষয়টি দেখুন। একটি 26.04 laptop একটি 24.04 server-এ সংযোগ করে। Client-এর প্রথম পছন্দ mlkem768x25519-sha256, যা 9.6 server-এর তালিকায় নেই। Server-এ থাকা client-এর পরবর্তী post-quantum পছন্দ হলো sntrup761x25519-sha512@openssh.com, এবং ssh -v এই নামটিই report করে। কারও কোনো configuration ছাড়াই, 2024 সালে তৈরি server-এর সঙ্গে এই session-এর key exchange post-quantum থাকে।

22.04-এর ক্ষেত্রে ফলটি উল্টো, এবং এটি দেখায় কেন শুধু ssh -Q kex বিভ্রান্তিকর। OpenSSH 8.9 sntrup761x25519-sha512@openssh.com নামটি জানে, তাই ওই মেশিনে 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-এ সংযোগ করছেন তার একটি বৈশিষ্ট্য; এটি আপনার client সম্পর্কে নয়। সমাধান হলো server upgrade করা। WarnWeakCrypto no সেট করলে message-টি সরবে, কিন্তু connection-এ কোনো পরিবর্তন হবে না।

হাইব্রিড পদ্ধতি কেন, এবং harvest now, decrypt later বলতে কী বোঝায়

হুমকির ধরন সরল। আপনার network traffic দেখতে পারে এমন কোনো আক্রমণকারী আজ encrypted byte-গুলো record করে সংরক্ষণ করে। আজ সে সেগুলো পড়তে পারে না। X25519 ভাঙার মতো যথেষ্ট বড় quantum computer তৈরি না হওয়া পর্যন্ত সে অপেক্ষা করে, তারপর সেগুলো পড়ে। এটিকে harvest now, decrypt later বা store now, decrypt later বলা হয়। বর্তমানে আক্রমণকারীকে কোনো জটিল কৌশল ব্যবহার করতে হয় না। তার দরকার disk space এবং ধৈর্য।

এই সমস্যা encryption-এর আছে, কিন্তু signature-এর নেই। এই অসমতাই পরবর্তী সব সিদ্ধান্তকে প্রভাবিত করে। ডেটার ভেতরের তথ্য যতক্ষণ sensitive থাকে, recorded ciphertext ততক্ষণ মূল্যবান থাকে। অন্যদিকে, যাচাই করার মুহূর্তে signature-কে শুধু জাল করা অসম্ভব হতে হয়। 2035 সালে কোনো signature algorithm ভেঙে ফেললে কেউ 2035 সালে server সেজে পরিচয় জাল করতে পারবে। কিন্তু সে 2026 সালের কোনো login-এর signature পরে গিয়ে জাল করতে পারবে না। তাই প্রথমে key exchange ঠিক করা জরুরি ছিল; signature-এর দিকটি পরে করা যায়।

Hybrid পদ্ধতিতে উভয় algorithm চলে এবং উভয়ের ফল session key তৈরিতে ব্যবহৃত হয়। mlkem768x25519-sha256-এর পেছনের secret উদ্ধার করতে আক্রমণকারীকে ML-KEM 768 এবং X25519 উভয়ই ভাঙতে হবে। এই জোড়াটি ইচ্ছাকৃত। ML-KEM, X25519-এর তুলনায় অনেক নতুন এবং cryptanalyst-দের আক্রমণের অধীনে থাকার সময়ও অনেক কম পেয়েছে। তাই নতুন algorithm-এ কোনো flaw পাওয়া গেলেও আপনি আগে থেকে থাকা সুরক্ষা হারাবেন না।

যা সুরক্ষিত এবং যা সুরক্ষিত নয়

Key exchange সুরক্ষিত। আপনার session encrypt করা shared secret একটি hybrid exchange থেকে এসেছে। তাই আজ সেই session record করলেও quantum computer চালু হলে তা পাঠযোগ্য হয়ে যাবে না।

Host key সুরক্ষিত নয়। debug1: kex: host key algorithm: ssh-ed25519 line-এ একটি classical signature-এর নাম আছে। rsa-sha2-512 এবং ECDSA (elliptic curve digital signature algorithm) type-গুলোর ক্ষেত্রেও একই কথা প্রযোজ্য। কোনো attacker-এর কাছে কার্যকর quantum computer থাকলে সে সেই signature জাল করে আপনার server সেজে থাকতে পারে। তবে তা কেবল ভবিষ্যতে সেই সময়ের একটি live connection-এর ক্ষেত্রে সম্ভব হবে। এখন record করা traffic-এর বিরুদ্ধে কখনোই নয়।

আপনার login key-ও সুরক্ষিত নয়। ~/.ssh/id_ed25519-এর key একই ধরনের classical signature। তাই একই যুক্তি এখানে প্রযোজ্য। এই বছর ওই key-কে যা সুরক্ষিত রাখে তা হলো key-টি কোথায় থাকে এবং কারা তা পড়তে পারে। তাই সুবিবেচিত SSH key management এই page-এ থাকা কোনো algorithm name-এর তুলনায় আপনার প্রকৃত ঝুঁকি অনেক বেশি কমিয়ে দেয়।

এই দুটির কোনোটির জন্যই আপনার কিছু করার নেই, কারণ বদলে ব্যবহার করার মতো কিছু নেই। OpenSSH জানিয়েছে, post-quantum signature support ভবিষ্যতের একটি release-এ আসছে। এটি release না হওয়া পর্যন্ত OpenSSH-এ কোনো post-quantum host key type বা post-quantum user key type নেই। ssh-keygen-এও আপনাকে দেওয়ার মতো এমন কিছু নেই। কোনো guide-এ আপনাকে এটি generate করতে বলা হলে সেটি এখনো অস্তিত্বহীন software-এর বর্ণনা দিচ্ছে।

একই server-এ TLS একটি আলাদা বিষয়, যার উত্তরও আলাদা। TLS (transport layer security) হলো আপনার web server port 443-এ যে protocol ব্যবহার করে। এটি আলাদা 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-এর সঙ্গে সরবরাহ করা version-এ আপনাকে রাখে, আর নতুন Ubuntu release-এ যাওয়াই আপনাকে নতুন OpenSSH-এ নিয়ে যায়। unattended security upgrades চালু করলে আপনাকে মনে না রাখলেও এই patch-গুলো প্রয়োগ হয়। কোনো algorithm-এর নাম অনুসরণ করতে source থেকে OpenSSH build করা ভালো সিদ্ধান্ত নয়, কারণ এতে সিস্টেমের সবচেয়ে বেশি exposed service-এর জন্য distribution-এর security update পাওয়া বন্ধ হয়ে যায়। তারপরও source সংগ্রহ করলে build করার আগে download-টি প্রকাশিত checksum-এর সঙ্গে মিলিয়ে দেখুন।

নিজে হাতে কোনো KexAlgorithms line লিখবেন না। এটিই একমাত্র পদক্ষেপ যা নির্ভরযোগ্যভাবে পরিস্থিতি আরও খারাপ করে। 2018 সালের একটি hardening guide আপনাকে এমন একটি তালিকা দিতে পারে যা 2018 সালে সঠিক ছিল, কিন্তু সেটি sshd_config-এ paste করলে default list-এ যোগ হয় না; বরং সেটি প্রতিস্থাপিত হয়। এরপর থেকে তৈরি হওয়া প্রতিটি algorithm বাদ পড়ে, ফলে যে server নিজে থেকেই mlkem768x25519-sha256 negotiate করতে পারত, সেটি নীরবে pinned list-এ টিকে থাকা বিকল্পে নেমে যায়। উত্তরাধিকারসূত্রে পাওয়া যেকোনো server-এ sudo sshd -T | grep -i '^kexalgorithms' চালান। একই release-এর fresh install-এ থাকা তালিকার তুলনায় ওই line ছোট হলে বুঝবেন, কেউ সেটি pin করেছে।

তালিকা পরিবর্তনের প্রকৃত কারণ থাকলে সেটি প্রতিস্থাপন না করে এতে যোগ করুন। OpenSSH শুরুর +-কে append, শুরুর --কে remove এবং শুরুর ^-কে তালিকার শুরুতে সরানোর নির্দেশ হিসেবে পড়ে।

KexAlgorithms ^mlkem768x25519-sha256

ফাইলটির ওপর নির্ভর করার আগে পরীক্ষা করুন। sudo sshd -t configuration parse করে এবং configuration valid হলে কিছু print করে না। build-এ না থাকা কোনো algorithm-এর নাম উল্লেখ করা KexAlgorithms line থাকলে sshd start হওয়া বন্ধ হয়ে যায়। Remote box-এ এর অর্থ হলো আপনি আর ঢুকতে পারবেন না। তাই কাজ করার সময় দ্বিতীয় একটি session খোলা রাখুন। দুই পাশের list-এ আর কোনো common 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-এর নাম এবং এটি কোন protocol-এর ক্ষেত্রে প্রযোজ্য, তা জিজ্ঞাসা করুন। August 2026-এ OpenSSH সম্পর্কে এই দাবির সৎ ব্যাখ্যা হলো: key exchange hybrid post-quantum, কিন্তু signature-গুলো classical। এর চেয়ে বিস্তৃত কোনো দাবি হলে তার সঙ্গে এমন একটি নাম থাকা উচিত, যা ssh -Q kex output-এ খুঁজে পাওয়া যায়।

রুটিন কাজগুলো চালিয়ে যান। post-quantum key exchange অনুমান করা সহজ password-এর বিরুদ্ধে কিছুই করে না। পরে চুরি হওয়া laptop-এ কপি করা private key-এর বিরুদ্ধেও এটি কিছু করে না। আসলে এগুলোই server দখল করে, এবং VPS-এ standard SSH hardening এখনও প্রায় পুরো সুরক্ষার ভার বহন করে। এখানে negotiation-এর ধাপগুলো অপরিচিত হলে আপনি connect করলে SSH কী করে এই পৃষ্ঠায় ধরে নেওয়া ধাপগুলো ব্যাখ্যা করে।

FAQ

আমার SSH connection কি ইতিমধ্যে post-quantum?

`ssh -v yourserver 2>&1 | grep 'kex: algorithm' চালিয়ে সেটি যে নাম দেখায় তা পড়ুন। mlkem768x25519-sha256 এবং sntrup761x25519-sha512@openssh.com hybrid post-quantum exchange। curve25519-sha256, ecdh-sha2-nistp256 এবং যেকোনো diffie-hellman-group` নাম classical। উভয় প্রান্তে post-quantum নাম সমর্থনকারী একটি version থাকতে হবে, কারণ negotiation এমন একটি client choice বেছে নেয় যা server-ও সমর্থন করে। তাই পুরোনো 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-এ দুটির কোনোটিই negotiate না হলে warning দেখানো শুরু করেছে। আপনার Ubuntu release কোনটি দিচ্ছে তা নির্ধারণ করে, তাই ssh -Q kex এবং ssh -G <host>` ব্যবহার করে আপনার নিজের build কী করে তা পরীক্ষা করুন।

আমার কি post-quantum SSH key তৈরি করা উচিত?

না, কারণ OpenSSH-এ এমন কোনো key type নেই। এখন পর্যন্ত post-quantum কাজ key exchange পর্যন্ত সীমাবদ্ধ। এর জন্য আপনার কোনো key file বা কোনো configuration প্রয়োজন হয় না। Host key এবং login key এখনও Ed25519 ও RSA-এর মতো classical signature ব্যবহার করে। Upstream জানিয়েছে যে post-quantum signature ভবিষ্যতের কোনো release-এ আসবে। Ed25519 key ব্যবহার চালিয়ে যান এবং এটি যেখানে সংরক্ষিত আছে সেই স্থান সুরক্ষিত রাখুন।

ssh কেন warning দেয় যে আমার connection post-quantum নয়?

OpenSSH 10.1 এবং পরবর্তী version-গুলো negotiated exchange-এ post-quantum অংশ না থাকলে `** WARNING: connection is not using a post-quantum key exchange algorithm. দেখায়। Warning-টি server সম্পর্কে, client সম্পর্কে নয়, কারণ আপনার client একটি post-quantum নাম প্রস্তাব করেছিল কিন্তু server সেগুলোর কোনোটি গ্রহণ করেনি। Server-এর OpenSSH upgrade করুন, অথবা তার sshd_config-এ কেউ এমন KexAlgorithms line নির্দিষ্ট করেছে কি না পরীক্ষা করুন যা আধুনিক নামগুলো বাদ দেয়। WarnWeakCrypto no` সেট করলে message-টি লুকাবে, কিন্তু connection আগের মতোই দুর্বল থাকবে।