GitHub-এ পুরোনো SSH ভাঙতে পারে—RSA key বদলানোর আগে এই পরীক্ষা করুন

GitHub-এর ২২ সেপ্টেম্বর ২০২৬-এর SSH নিরাপত্তা ঘোষণা অনুযায়ী, ১৪ অক্টোবর থেকে নতুন আপলোড করা RSA key কমপক্ষে ৩০৭২-bit হতে হবে; SHA-1-ভিত্তিক ssh-rsa স্বাক্ষর ও একটি পুরোনো key exchange পদ্ধতি সরানোর প্রথম সাময়িক পরীক্ষা নির্ধারিত ৪ নভেম্বর। স্বাক্ষর ও key exchange পদ্ধতি সরানোর পরিবর্তন এখনো সম্পূর্ণ কার্যকর হয়নি, তবে পুরোনো SSH client দিয়ে GitHub-এ যুক্ত হওয়া Git কাজ সেই পরীক্ষার সময় ব্যর্থ হতে পারে।

বিদ্যমান RSA key থাকলেই সেটি বদলাতে হবে, এমন সিদ্ধান্ত এই ঘোষণায় নেই। একই key দিয়ে client যদি RSA/SHA-2 স্বাক্ষর তৈরি করতে পারে, সেটি ব্যবহার করা যাবে। তাই key বদলানোর আগে দেখতে হবে সংশ্লিষ্ট Git কাজটি SSH ব্যবহার করছে কি না, কোন client সংযোগ করছে এবং সংযোগে কোন স্বাক্ষর পদ্ধতি নির্বাচিত হচ্ছে। নিজের কম্পিউটারের সফল পরীক্ষা কোনো স্বয়ংক্রিয় কাজের client সম্পর্কে একই ফল প্রমাণ করে না।

কোন remote ও কাজ পরীক্ষার আওতায়

প্রথমে সংশ্লিষ্ট repository-তে git remote -v চালান। URL যদি [email protected]: দিয়ে শুরু হয় অথবা ssh:// দিয়ে GitHub-এ যায়, সেই Git কাজ SSH ব্যবহার করছে। https:// দিয়ে শুরু হওয়া remote এই নির্দিষ্ট SSH অ্যালগরিদম পরিবর্তনের আওতায় পড়ে না। একই repository-তে fetch ও push-এর URL আলাদা থাকতে পারে; তাই দুই দিকই দেখুন।

Submodule থাকলে git submodule foreach --recursive 'git remote -v' চালিয়ে সেগুলোর remote-ও দেখুন। একটি HTTPS মূল repository-র submodule SSH ব্যবহার করতে পারে। আবার remote-র সংরক্ষিত URL ও Git-এর কার্যকর URL এক নাও হতে পারে: URL বদলানোর নিয়ম ব্যবহৃত হলে git remote get-url origin এবং push-এর জন্য git remote get-url --push origin দিয়ে কার্যকর ঠিকানা মিলিয়ে নিন। CI runner বা deploy job-এর ক্ষেত্রে কমান্ডগুলো সেই কাজ চলার পরিবেশে চালাতে হবে।

RSA key আর ssh-rsa স্বাক্ষর আলাদা কেন

Public key-র শুরুতে ssh-rsa লেখা থাকলে সেটি key-র ধরন, সংযোগে ব্যবহৃত স্বাক্ষর পদ্ধতির প্রমাণ নয়। স্বাক্ষর পদ্ধতির নামও ssh-rsa হলে সেখানে RSA-র সঙ্গে SHA-1 ব্যবহার হয়; ঘোষিত অপসারণটি এই পদ্ধতির। একই RSA key দিয়ে rsa-sha2-256 বা rsa-sha2-512 স্বাক্ষর করা যায়, যদি প্রকৃত SSH client তা সমর্থন করে। শুধু public key-র প্রথম শব্দ দেখে তাই ঝুঁকি নির্ধারণ করা যায় না।

নতুন RSA key-র দৈর্ঘ্যের শর্তটিও স্বাক্ষরের প্রশ্ন থেকে পৃথক। নতুন key আপলোডের নিয়মকে আগে যোগ করা সব RSA key বাতিলের ঘোষণা ধরে নেওয়া ভুল। অন্যদিকে যথেষ্ট দীর্ঘ key থাকলেও client কেবল SHA-1 স্বাক্ষর করতে পারলে সেই সংযোগ ঝুঁকিতে থাকবে। key বদলানোর সিদ্ধান্তে দৈর্ঘ্য, আগে থেকে যোগ করা key-র অবস্থা এবং সংযোগের সময় নির্বাচিত পদ্ধতি আলাদাভাবে বিবেচনা করতে হবে।

যে client সত্যি সংযোগ করছে, সেটি কীভাবে যাচাই করবেন

1. কাজটি যেখানে চলে, সেখানে ssh -V দিয়ে OpenSSH-এর সংস্করণ দেখুন এবং git config --get core.sshCommand দিয়ে Git আলাদা SSH কমান্ড ব্যবহার করছে কি না দেখুন। GIT_SSH বা GIT_SSH_COMMAND নির্ধারিত থাকলে সেগুলোও হিসাবের মধ্যে নিন। কোনো অ্যাপ নিজস্ব SSH library ব্যবহার করলে সিস্টেমের ssh -V সেই অ্যাপের সংস্করণ জানায় না।
2. কাজটি OpenSSH দিয়ে চললে ssh -vvv -T [email protected] চালিয়ে বিস্তারিত বার্তায় ব্যবহৃত key এবং signing using অংশ দেখুন। সেখানে rsa-sha2-256 বা rsa-sha2-512 থাকলে পরীক্ষিত authentication-এ RSA/SHA-2 স্বাক্ষর ব্যবহৃত হয়েছে। ssh-rsa স্বাক্ষর দেখা গেলে ঘোষিত অপসারণে সেই পথ প্রভাবিত হবে। শুধু client-এর সমর্থিত বা প্রস্তাবিত অ্যালগরিদমের তালিকা দেখে নির্বাচিত পদ্ধতি ধরে নেবেন না।
3. একই বিস্তারিত বার্তায় নির্বাচিত kex: algorithm দেখুন। GitHub diffie-hellman-group-exchange-sha256 key exchange-ও সরানোর পরিকল্পনা করেছে। এটি authentication-এর স্বাক্ষর থেকে আলাদা ধাপ; Ed25519 key নিলেও client কেবল ওই key exchange পদ্ধতিতে সীমাবদ্ধ থাকলে সংযোগের সমস্যা দূর হবে না।
4. শেষে সংশ্লিষ্ট repository থেকে git ls-remote origin HEAD চালিয়ে পড়ার কাজটি পরীক্ষা করুন। SSH-তে পরিচয় যাচাই সফল হলেও repository-তে অনুমতি না থাকলে Git কাজ ব্যর্থ হতে পারে। অ্যাপ বা CI পণ্য নিজস্ব SSH library ব্যবহার করলে তার প্রকৃত clone, fetch বা push কাজের ফলও দেখতে হবে।

GitHub-এর SSH পরীক্ষায় পরিচয় যাচাই সফল হলেও interactive shell পাওয়া যায় না; তাই কেবল কমান্ডের exit status-কে ব্যর্থতার প্রমাণ ধরবেন না। বিপরীতে, বিস্তারিত বার্তায় স্বাক্ষরের লাইন না পাওয়া SHA-1 ব্যবহৃত হয়নি—এমন নিশ্চয়তা দেয় না। কোন key, client ও Git কাজ পরীক্ষা হয়েছে, ফলের সঙ্গে সেটি মিলিয়ে দেখুন।

সংস্করণ দেখার পর key নিয়ে সিদ্ধান্ত

প্রকাশিত উপযুক্ত সংস্করণের তালিকায় OpenSSH 7.2p1, নির্দিষ্ট JSch fork-এর 0.1.66, TeamCity 2021.2.3, Go SSH 0.16.0, libssh2 1.11.0 এবং PuTTY 0.82 রয়েছে। এগুলো ডিফল্ট কনফিগারেশনে RSA/SHA-2 সমর্থন যাচাইয়ের সূচনা বিন্দু; সংশ্লিষ্ট পণ্যে কোন library যুক্ত আছে, সেটিও জানতে হবে। পুরোনো সংস্করণ দেখলে আগে client হালনাগাদের সুযোগ পরীক্ষা করুন, তারপর একই GitHub কাজ আবার চালান।

• RSA key রাখুন: প্রকৃত client RSA/SHA-2 স্বাক্ষর ব্যবহার করছে এবং সংশ্লিষ্ট Git কাজ সফল হলে শুধু এই পরিবর্তনের কারণে বিদ্যমান key বদলানোর প্রয়োজন নেই। একই key অন্য automation-এ থাকলে সেখানকার client-ও পৃথকভাবে যাচাই করুন।
• Ed25519 নিন: নতুন SSH key প্রয়োজন হলে এবং client এটি সমর্থন করলে এটি যুক্তিসংগত পথ। GitHub-এর key তৈরির নির্দেশনা ssh-keygen -t ed25519 দিয়ে key তৈরি, private key ssh-agent-এ যোগ এবং public key অ্যাকাউন্টে যোগ করার ধাপ দেখায়। বিদ্যমান key সরানোর আগে নতুন key দিয়ে প্রয়োজনীয় Git কাজ সফল হয় কি না মিলিয়ে নিন।
• HTTPS ব্যবহার করুন: SSH client দ্রুত হালনাগাদ করা না গেলে remote HTTPS-এ নেওয়া এই SSH পরিবর্তন এড়ানোর একটি পথ। স্বয়ংক্রিয় কাজে তখন HTTPS-এর উপযুক্ত credential ও repository-র অনুমতিও সাজাতে হবে; শুধু remote URL পাল্টানো যথেষ্ট নয়।

ঘোষিত সময়সূচিতে নতুন RSA key-র শর্ত এবং প্রথম সাময়িক পরীক্ষার দিন স্পষ্ট। তবে চূড়ান্ত অপসারণের জন্য লেখা সাল আগের ঘটনাগুলোর ক্রমের সঙ্গে মেলে না; নান্দানের সাম্প্রতিক বিশ্লেষণও এই অসংগতি চিহ্নিত করেছে। সংশোধিত চূড়ান্ত দিন নিশ্চিত না হওয়া পর্যন্ত সেটিকে নির্ভরযোগ্য শেষ সময়সীমা ধরা যাচ্ছে না।

আরও পড়ুন:

• GitHub Actions-এ নতুন ডিফল্ট বাধা—২ নভেম্বর ভাঙতে পারে কিছু workflow
• GitHub-এ SHA-1 HTTPS বন্ধ—পুরোনো Git client এখন connection হারাতে পারে
• ChatGPT login ব্যর্থ? Password বদলানোর আগে outage আর account আলাদা করুন