Ubuntu-তে Post-Quantum SSH: কী পরিবর্তন হয়েছে

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

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

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

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

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

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

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

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 তারিখে প্রকাশিত, sntrup761x25519-sha512@openssh.com যোগ করে এবং এটিকে default হিসেবে disabled রাখে।
• 9.0, 2022-04-08 তারিখে প্রকাশিত, এটি চালু করে। Notes-এ বলা হয়েছে, OpenSSH default হিসেবে “hybrid Streamlined NTRU Prime + x25519 key exchange method” ব্যবহার করবে। এই release থেকেই post-quantum key exchange স্বাভাবিক পদ্ধতি হয়ে যায়।
• 9.9, 2024-09-19 তারিখে প্রকাশিত, দ্বিতীয় option হিসেবে mlkem768x25519-sha256 যোগ করে। একই release-এ পুরোনো method-টির IANA-registered name sntrup761x25519-sha512 দেওয়া হয়। তাই নতুন build-গুলোতে এটি দুই নামেই তালিকাভুক্ত থাকে।
• 10.0, 2025-04-09 তারিখে প্রকাশিত, key agreement-এর জন্য mlkem768x25519-sha256-কে default করে।
• 10.1, 2025-10-06 তারিখে প্রকাশিত, কোনো connection post-quantum half ছাড়া key exchange negotiate করলে client warning যোগ করে। এটি ssh_config-এর WarnWeakCrypto option দ্বারা নিয়ন্ত্রিত এবং default হিসেবে চালু থাকে।

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

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

Ubuntu কোনো release-এর সময় OpenSSH-এর একটি version স্থির করে, তারপর version number পরিবর্তন না করে তাতে security fix backport করে। তাই আপনি যে Ubuntu release ব্যবহার করছেন, সেটিই আপনার default algorithm নির্ধারণ করে। কোনো তালিকার ওপর নির্ভর না করে ssh -V দিয়ে আপনার সামনে থাকা machine পরীক্ষা করুন। 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 রয়েছে। এটি mlkem768x25519-sha256-কে default হিসেবে ব্যবহার করে এবং post-quantum নয় এমন connection সম্পর্কে warning দেয়।

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

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 দেখতে পারে এমন কোনো attacker আজ encrypted byte-গুলো রেকর্ড করে সংরক্ষণ করতে পারে। আজ তারা সেগুলো পড়তে পারবে না। পর্যাপ্ত বড় quantum computer-এ X25519 ভাঙার সক্ষমতা তৈরি হওয়া পর্যন্ত তারা অপেক্ষা করবে, তারপর সেগুলো পড়বে। একে harvest now, decrypt later বা store now, decrypt later বলা হয়। বর্তমানে attacker-এর কোনো জটিল কৌশল দরকার নেই। শুধু disk space এবং ধৈর্য দরকার।

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

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

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

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 এই পৃষ্ঠায় থাকা কোনো algorithm-এর নামের চেয়ে আপনার প্রকৃত ঝুঁকি অনেক বেশি কমায়।

এই দুটির কোনোটির ক্ষেত্রেই আপনার কিছু করার নেই, কারণ বিকল্প হিসেবে ব্যবহার করার মতো কিছু নেই। 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) হলো আপনার web server যে protocol-এ port 443-এ যোগাযোগ করে। এটি ভিন্ন codebase এবং ভিন্ন release schedule অনুসরণ করে। OpenSSH upgrade করলে TLS-এর কোনো পরিবর্তন হয় না। আপনি যদি একই VPS-এ private service-এর জন্য self-signed certificate ব্যবহার করেন, তবে সেই certificate-এর signature এবং key exchange OpenSSL ও আপনার web server নির্ধারণ করে। তাই এই stack-কে তার নিজস্ব নিয়ম অনুযায়ী আলাদাভাবে মূল্যায়ন করুন।

এখন একজন বিচক্ষণ অপারেটর যা করবেন

OpenSSH হালনাগাদ রাখুন, এবং সেখানেই থামুন। এই সমস্যার জন্য কৌশলটি সত্যিই এতটুকুই। sudo apt update && sudo apt upgrade আপনার Ubuntu release-এর সঙ্গে সরবরাহ করা version-এই রাখে, আর নতুন OpenSSH পেতে হলে নতুন Ubuntu release-এ upgrade করতে হয়। unattended security upgrades চালু করলে আপনাকে মনে না রাখলেও এই patch-গুলো প্রয়োগ হয়। কোনো algorithm name অনুসরণ করতে source থেকে OpenSSH build করা ভালো সিদ্ধান্ত নয়, কারণ এতে সার্ভারের সবচেয়ে বেশি exposed service-এর জন্য distribution-এর security update আর পাওয়া যায় না। তবু source সংগ্রহ করলে build করার আগে published checksum-এর সঙ্গে download মিলিয়ে দেখুন।

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

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

KexAlgorithms ^mlkem768x25519-sha256

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

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

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। উভয় প্রান্তে এমন version থাকতে হবে যা একটি post-quantum নাম সমর্থন করে। কারণ negotiation-এ client-এর প্রথম পছন্দটি নেওয়া হয়, যদি server-ও সেটি সমর্থন করে। তাই পুরোনো 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-এ দুটির কোনোটিই 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 আগের মতোই দুর্বল থাকবে।