Linux-এ checksum দিয়ে download যাচাই করুন

দুই মিনিটে checksum দিয়ে একটি download যাচাই করুন

checksum দিয়ে একটি download যাচাই করতে, আপনার পাওয়া file-টির hash তৈরি করুন এবং একটি tool-কে সেই hash publisher-এর প্রকাশ করা hash-এর সঙ্গে তুলনা করতে দিন। sha256sum কাজটির উভয় অংশই করে: একা চালালে এটি একটি digest দেখায়, আর -c দিয়ে চালালে এটি digest-এর একটি তালিকা পড়ে এবং কোন file মিলে তা জানায়। এই guide-এ আপনি নিজে তৈরি করা একটি file দিয়ে পুরো প্রক্রিয়াটি চালাবেন। এরপর ইচ্ছাকৃতভাবে সেই file পরিবর্তন করবেন, যাতে ব্যর্থতা সম্পর্কে শুধু পড়ার পরিবর্তে সেটি নিজে ঘটতে দেখেন।

পুরো প্রক্রিয়ায় একটি বাক্য মনে রাখুন। checksum জানায়, আপনার কাছে থাকা bytes-গুলো digest তৈরি করা bytes-গুলোর সঙ্গে মেলে কি না। তবে digest কে তৈরি করেছে, সে সম্পর্কে checksum কিছুই জানায় না। দ্বিতীয় প্রশ্নের উত্তর পেতে signature এবং আপনার বিশ্বস্ত key প্রয়োজন। এই guide-এর শেষ অংশে checksum ও signature-এর মধ্যে পার্থক্যটি ঠিক কোথায়, তা দেখানো হয়েছে।

অনুশীলনের জন্য একটি ফাইল তৈরি করুন

একটি অস্থায়ী ডিরেক্টরিতে কাজ করুন, যাতে এখানকার কোনো কাজ সিস্টেমের অন্য অংশে প্রভাব না ফেলে। নিচের প্রতিটি কমান্ড GNU coreutils থেকে এসেছে। এগুলো যেকোনো Ubuntu বা Debian সার্ভারে থাকা মৌলিক কমান্ড সেটের অংশ। তাই কিছু ইনস্টল করার প্রয়োজন নেই।

mkdir -p ~/checksum-demo
cd ~/checksum-demo
printf 'the payload of a totally ordinary download\n' > payload.txt
sha256sum payload.txt

আপনি একটি লাইন পাবেন: 64টি hexadecimal অক্ষর, দুটি space, তারপর ফাইলের নাম। ওই 64টি অক্ষর হলো ফাইলের digest। কমান্ডটি আবার চালালে একই লাইন পাওয়া যাবে, কারণ hashing deterministic: একই input সবসময় একই output দেয়। ফাইলের একটি অক্ষর পরিবর্তন করে আবার কমান্ডটি চালালে digest সামান্য পরিবর্তিত হবে না। এটি সম্পূর্ণ ভিন্ন দেখাবে, কারণ input-এর একটি bit পরিবর্তিত হলে output-এর প্রায় অর্ধেক bit পরিবর্তিত হয়। এই বৈশিষ্ট্যের কারণেই 64 অক্ষরের একটি string 4 GB image-এর নির্ভরযোগ্য প্রতিনিধিত্ব হিসেবে ব্যবহার করা যায়।

একটি SHA256SUMS ফাইল সংরক্ষণ করুন, তারপর সেটি পরীক্ষা করুন

স্ক্রিনে দেখা একটি digest এক দিন পর আর কোনো কাজে আসে না। এটি একটি ফাইলে লিখুন, যে format-এ sha256sum নিজেই লেখে, যাতে tool পরে সেটি পড়তে পারে।

sha256sum payload.txt > SHA256SUMS
cat SHA256SUMS
sha256sum -c SHA256SUMS

sha256sum -c তালিকার প্রতিটি line পড়ে, সেই line-এ উল্লেখ করা file-এর hash তৈরি করে এবং দুটি digest তুলনা করে। সফলভাবে চললে প্রতিটি file-এর জন্য একটি করে line দেখায়:

payload.txt: OK

Exit status-ও পরীক্ষা করুন, কারণ script সেটিই পড়ে; text পড়ে না। সফলভাবে চলার পরে echo $?, 0 দেখায়। SHA256SUMS নামটি বাধ্যতামূলক নিয়ম নয়, এটি একটি প্রচলিত convention। তবে distribution এবং অধিকাংশ release page এই নাম ব্যবহার করে। তাই আপনিও এটি ব্যবহার করুন, যাতে পরের ব্যক্তি file না খুলেও বুঝতে পারেন সেটিতে কী আছে।

একটি byte পরিবর্তন করে check ব্যর্থ হতে দেখুন

এখন ইচ্ছাকৃতভাবে ফাইলটি নষ্ট করুন। এই কমান্ডটি offset 5-এ একটি byte লেখে এবং বাকি সব অপরিবর্তিত রাখে। তাই ফাইলের দৈর্ঘ্য ও নাম অপরিবর্তিত থাকে।

printf 'X' | dd of=payload.txt bs=1 seek=5 conv=notrunc status=none
cat payload.txt
sha256sum -c SHA256SUMS

এখানে conv=notrunc flag-টিই গুরুত্বপূর্ণ। এটি না থাকলে dd যেখানে লেখা থামায়, সেখানেই ফাইলটি truncate করে দিত। তখন আপনি অনেক বেশি স্পষ্ট ধরনের ক্ষতি পরীক্ষা করতেন। এখন check-এর output হবে:

payload.txt: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match

echo $?, 1 print করে। FAILED-এর অর্থ হলো ফাইলটি পড়া হয়েছে, কিন্তু এর digest তালিকায় থাকা digest-এর সঙ্গে মেলেনি। মূল byte-গুলো ফিরিয়ে দিন এবং নিশ্চিত করুন যে check আবার OK অবস্থায় ফিরে এসেছে:

printf 'the payload of a totally ordinary download\n' > payload.txt
sha256sum -c SHA256SUMS

এটাই পুরো প্রক্রিয়া। ফাইলের যেকোনো স্থানে একটি byte-এর পার্থক্য থাকলেই FAILED তৈরি হয়। সংযোগ বিচ্ছিন্ন হয়ে অসম্পূর্ণ download, গতকালের build সরবরাহ করা mirror, transit-এর সময় ফাইল পরিবর্তন করা proxy, অথবা ভুল block ফেরত দেওয়া disk—সব ক্ষেত্রেই একই ফল দেখা যায়।

যখন তালিকায় এমন একটি ফাইলের নাম থাকে যা আপনি download করেননি

একটি প্রকৃত SHA256SUMS ফাইলে distribution যে সব image release করে, সেগুলোর তালিকা থাকে। আপনি সেগুলোর একটি download করেছেন। এখানে সেই পরিস্থিতিটি পুনরায় তৈরি করুন।

printf 'a second file\n' > notes.txt
sha256sum payload.txt notes.txt > SHA256SUMS.all
rm notes.txt
sha256sum -c SHA256SUMS.all

payload.txt: OK
sha256sum: notes.txt: No such file or directory
notes.txt: FAILED open or read
sha256sum: WARNING: 1 listed file could not be read

FAILED open or read হলো FAILED থেকে আলাদা ধরনের ব্যর্থতা, এবং দুটিকে গুলিয়ে ফেললে অপ্রয়োজনীয় সময় নষ্ট হয়। FAILED-এর অর্থ হলো byte-গুলো সঠিক নয়। FAILED open or read-এর অর্থ হলো sha256sum ফাইলটি একেবারেই পায়নি, তাই কোনো তুলনা করা হয়নি। প্রকৃত download-এর ক্ষেত্রে সাধারণত working directory-ই কারণ, কারণ তালিকার নামগুলো আপনি যে directory থেকে command চালান, তার relative path হিসেবে ধরা হয়। ফাইলটি থাকা directory-তে যান এবং আবার command চালান। আপনার কাছে বাস্তবে থাকা ফাইলগুলোই পরীক্ষা করতে এভাবে অনুরোধ করুন:

sha256sum --ignore-missing -c SHA256SUMS.all

এটি payload.txt: OK মুদ্রণ করে এবং 0 exit status দিয়ে শেষ হয়। তালিকাভুক্ত নামগুলোর একটিও উপস্থিত না থাকলে, --ignore-missing শূন্যটি file-এর ক্ষেত্রে নীরবে সফল হয় না। এটি no file was verified জানায় এবং non-zero exit status দিয়ে শেষ হয়। এটাই প্রত্যাশিত আচরণ, কারণ কোনো কিছু পরীক্ষা না করেও সফল দেখানো এমন একটি ব্যর্থতা, যা আপনি কখনো জানতে পারতেন না।

চোখে না দেখে প্রকাশিত digest পেস্ট করুন

64টি hexadecimal character চোখে মিলিয়ে দেখা হলেই এই অভ্যাসটি ব্যর্থ হয়। অনেকে প্রথম চারটি character এবং শেষ চারটি character মিলিয়ে দেখে সেটিকে match বলে ধরে নেন। একজন পরিকল্পিত attacker ঠিক এই তুলনার ওপর নির্ভর করে। পরিবর্তে tool-কে তুলনা করতে দিন। publisher-এর কাছ থেকে কপি করা digest দিয়ে EXPECTED সেট করুন। এর জন্য প্রথমে EXPECTED= লিখে তার পরে কপি করা value বসান। তারপর -c যে single line প্রত্যাশা করে, সেটি তৈরি করুন:

printf '%s  %s\n' "$EXPECTED" payload.txt > payload.sha256
cat payload.sha256
sha256sum -c payload.sha256

digest এবং file name-এর মধ্যে দুটি space আছে। তাই format string-এও দুটি space রাখা হয়েছে। sha256sum যে format লেখে, এটিই তার কাঠামো। -c একই কাঠামো parse করে। শুধু একটি digest থাকা file কোনো checksum line নয়। তাই কোন file বোঝানো হয়েছে তা অনুমান না করে check পুরো file-টি no properly formatted checksum lines found দিয়ে প্রত্যাখ্যান করে। কিছু project এর পরিবর্তে BSD tagged style প্রকাশ করে: SHA256 (payload.txt) = -এর পরে digest থাকে। GNU coreutils sha256sum --tag payload.txt দিয়ে এই format লেখে এবং -c দিয়ে তা পড়ে। তাই যেকোনো একটি format সংরক্ষণ করা যায়।

Check অস্বাভাবিক আচরণ করলে cat -A SHA256SUMS দিয়ে list-টি নিজেই পরীক্ষা করুন। এটি প্রতিটি line-এর শেষে $ চিহ্ন দেখায় এবং অন্যথায় অদৃশ্য character-গুলো দৃশ্যমান করে। ^M$ দিয়ে শেষ হওয়া কোনো line Windows editor থেকে carriage return নিয়ে এসেছে। GNU sha256sum ওই trailing character উপেক্ষা করে এবং তবুও OK প্রিন্ট করে। তাই CRLF list আপনার check ব্যর্থ করার কারণ নয়, যদিও coreutils-এর বাইরের tool-গুলো এটি এতটা সহনশীলভাবে পরিচালনা নাও করতে পারে। tr -d '\r' < SHA256SUMS > SHA256SUMS.clean দিয়ে সংরক্ষণ করা copy-টি normalise করুন।

checksum কী প্রমাণ করে, আর কী প্রমাণ করে না?

একটি checksum একটি বিষয় প্রমাণ করে: আপনার disk-এর bytes-গুলোই প্রকাশিত digest তৈরি করেছে। এটি অনিচ্ছাকৃত ক্ষতির ক্ষেত্রে সম্পূর্ণ সুরক্ষা দেয়। এমন অসতর্ক আক্রমণকারীর ক্ষেত্রেও এটি কার্যকর, যে download mirror-এ file বদলেছে কিন্তু digest প্রকাশ করা page-টি পরিবর্তন করতে পারেনি।

এটি file-এর লেখক বা উৎস সম্পর্কে কিছুই প্রমাণ করে না। একটি digest হলো bytes সম্পর্কে তথ্য, মানুষের সম্পর্কে নয়। যদি একই page থেকে file এবং digest দুটিই পরিবেশন করা হয়, তাহলে যে ব্যক্তি একটিতে পরিবর্তন করতে পারে, সে অন্যটিতেও পরিবর্তন করতে পারে। সে ক্ষেত্রে আপনার OK line শুধু প্রমাণ করে যে mirror নিজের সঙ্গেই একমত। তাই checksums চালানোর মূল নিয়ম হলো: file যেখান থেকে নিয়েছেন, digest তার অন্য কোনো উৎস থেকে নিন। উদাহরণস্বরূপ, image যদি mirror বা torrent থেকে নেওয়া হয়, তাহলে TLS (transport layer security)-এর মাধ্যমে project-এর নিজস্ব domain থেকে digest নিন। এতে আক্রমণকারীকে একটি জায়গার বদলে দুটি জায়গা নিয়ন্ত্রণ করতে হবে।

Algorithm-টিও গুরুত্বপূর্ণ। SHA-256 (secure hash algorithm, 256-bit output)-এর ক্ষেত্রে August 2026 পর্যন্ত কোনো পরিচিত collision নেই। এ কারণেই publisher-রা এটি ব্যবহার করে। MD5 (message digest 5) এবং SHA-1 নির্ভরযোগ্য নয়: একই MD5 digest-সহ দুটি আলাদা file 2004 সাল থেকে তৈরি করা সম্ভব, এবং chosen-prefix SHA-1 collision 2020 সালে প্রকাশিত হয়েছে। একটি MD5SUMS file truncated download শনাক্ত করতে পারে, কারণ এলোমেলো corruption crafted collision নয়। তবে আপনাকে প্রতারণা করার চেষ্টা করা কাউকে এটি থামাতে পারে না। কোনো project যদি দুটিই প্রকাশ করে, তাহলে SHA-256 line ব্যবহার করুন।

স্বাক্ষর যেখানে যাচাইয়ের দায়িত্ব নেয়

একটি digest যে ফাঁকটি খোলা রাখে, স্বাক্ষর সেটি বন্ধ করে। publisher একটি private key দিয়ে digest file-এ স্বাক্ষর করে, আর আপনি তাদের public key দিয়ে সেটি যাচাই করেন: gpg --verify SHA256SUMS.asc SHA256SUMS। এটি সফল হলে digest-এর তালিকাটি ওই key-টি ধারণকারী পক্ষের কাছ থেকে এসেছে। এরপর sha256sum -c SHA256SUMS আপনার disk-এর file-টিকে ওই তালিকার সঙ্গে মিলিয়ে দেয়, এবং এই chain key থেকে শুরু করে শেষ পর্যন্ত byte পর্যন্ত পৌঁছে যায়।

দুর্বলতার স্থানটি তখন key-তে সরে যায়। যে page থেকে file সরবরাহ করা হয়েছে, সেই একই page থেকে key নিলে attacker উভয় অংশই নিয়ন্ত্রণে পেয়ে যায়। GnuPG এ বিষয়ে স্পষ্ট, এবং প্রথম verification-এ Good signature-এর সঙ্গে WARNING: This key is not certified with a trusted signature! প্রদর্শিত হয়। Good signature-এর অর্থ হলো গণিতগত যাচাই সঠিক। এর অর্থ এই নয় যে key-টি আপনার মনে থাকা project-এর। দ্বিতীয় কোনো উৎস থেকে fingerprint সংগ্রহ করুন, যেমন অন্য domain-এ থাকা project-এর documentation অথবা যে distribution package-এ key-টি আগে থেকেই অন্তর্ভুক্ত আছে। এরপর শেষ আটটি character নয়, সম্পূর্ণ fingerprint তুলনা করুন। একই কারণে এটিই একটি SSH private key-এর প্রাপ্য সতর্কতা: key-ই trust-এর সিদ্ধান্ত নির্ধারণ করে, এবং পরবর্তী সবকিছু সেই সিদ্ধান্তের ওপর নির্ভর করে।

Reproducible build এই ধারণাকে আরও এক ধাপ এগিয়ে নেয়। প্রকাশিত digest এখনও আপনাকে একটি নির্দিষ্ট machine-এ তৈরি binary-এর ওপর নির্ভরশীল করে। কোনো project-এর build reproducible হলে যে কেউ একই source compile করে byte-identical output পেতে পারে। ফলে independent builder-রা একটি server-এর কথার ওপর নির্ভর না করে প্রকাশিত digest নিশ্চিত করতে পারে। Automated pipeline এবং machine-written patch-এর মাধ্যমে প্রতি বছর আরও বেশি code আসায় এটি ক্রমেই গুরুত্বপূর্ণ হচ্ছে। কোনো build-এ কী গ্রহণ করবেন, সেটি একটি policy-সংক্রান্ত প্রশ্ন। AI-assisted code-এর জন্য open source policy-ও supply chain-এর অন্য প্রান্ত থেকে একই বিষয় নিয়ে কাজ করে।

আপনার package manager ইতিমধ্যে এটি করে

Debian এবং Ubuntu-তে, কোনো অতিরিক্ত নির্দেশ ছাড়াই প্রতিটি install-এর সময় apt এই chain চালায়। Package index-এ প্রতিটি .deb file-এর জন্য একটি SHA-256 digest থাকে। Release file-এ সেই index file-গুলোর digest থাকে, এবং InRelease-এ Release-এর ওপর একটি signature থাকে। এই signature /usr/share/keyrings এবং /etc/apt/trusted.gpg.d-এ থাকা key-এর সঙ্গে মিলিয়ে যাচাই করা হয়। chain-এ কোনো সমস্যা হলে apt তা জানায়: third-party repository-এর key না থাকলে The following signatures couldn't be verified because the public key is not available: NO_PUBKEY, অথবা আপনি যে index download করেছেন সেটি signed Release-এর সঙ্গে না মিললে Hash Sum mismatch। দ্বিতীয় পরিস্থিতির সাধারণ কারণ হলো caching proxy পুরোনো file সরবরাহ করেছে, অথবা mirror sync চলাকালীন আপনি সেটি পেয়েছেন।

কোনো project's home page যখন আপনাকে curl থেকে সরাসরি shell-এ একটি script pipe করতে বলে, তখন সেটিকে এই standard-এর সঙ্গে তুলনা করুন। এতে bytes যাচাই হয় না এবং আপনি সেগুলো দেখতেও পান না। Server একটি script-কে এক ধরনের content এবং browser-কে অন্য ধরনের content দিতে পারে। পরে পরীক্ষা করার জন্য আপনার কাছে কোনো copy-ও থাকে না। curl -fsSL <url> -o install.sh দিয়ে file-এ download করুন, hash নিন, less দিয়ে পড়ুন, এবং কেবল এরপর এটি চালান। এতে প্রায় বিশ সেকেন্ড সময় লাগে। কোনো অন্য কিছু install করার আগে একটি নতুন VPS-এ প্রথম দশ মিনিটেই এই অভ্যাস শুরু করা উচিত।

হাতে ইনস্টল করা উপাদানগুলোর জন্য digest-এর তালিকা রাখুন

apt দিয়ে ইনস্টল করা package-গুলোর হিসাব রাখা হয়। আপনি /usr/local/bin-এ কপি করা কোনো binary-এর হিসাব রাখা হয় না, এবং সিস্টেমের কোনো উপাদান সেটি পর্যবেক্ষণও করে না। একটি digest-এর তালিকা তৈরি করলে প্রয়োজনে তা যাচাই করা যায়:

printf 'a second file\n' > notes.txt
sha256sum *.txt > inventory.sha256
sha256sum -c --quiet inventory.sha256

সব file মিলে গেলে --quiet কিছুই প্রদর্শন করে না। কোনো file না মিললে শুধু ব্যর্থ হওয়া line-গুলো প্রদর্শন করে। তাই নীরব ফলাফলই pass, আর echo $? 0 দিয়ে তা নিশ্চিত করে। Scheduled job-এ ব্যবহারের জন্য এই পদ্ধতিই উপযুক্ত। --status আরও এগিয়ে কোনো output-ই দেয় না; শুধু exit status পাওয়া যায়। একই pattern-টি প্রকৃত file-এর ওপর sha256sum /usr/local/bin/* > ~/local-bin.sha256 দিয়ে প্রয়োগ করলে একটি baseline তৈরি হয়। তালিকায় path-গুলো আপনি যেভাবে লিখেছেন ঠিক সেভাবেই সংরক্ষিত হয়। তাই absolute path ব্যবহার করলে যেকোনো directory থেকে check কাজ করে।

এই baseline-এর সীমা স্পষ্টভাবে বুঝুন। এটি পরিবর্তিত file শনাক্ত করতে পারে। কিন্তু কোনো attacker ইতিমধ্যে root access পেয়ে গেলে তাকে শনাক্ত করতে পারে না, কারণ সেই attacker binary পুনরায় লেখার মতো সহজেই inventory.sha256-ও পরিবর্তন করতে পারে। তালিকাটি অর্থবহ রাখতে হলে সেটি machine-এর বাইরে সংরক্ষণ করুন। আপনি আসলে VPS-এর কতটা বিশ্বাস করছেন এবং এর নিচের disk-এ আর কারা পৌঁছাতে পারে, এটি সেই বৃহত্তর প্রশ্নেরই অংশ আপনি আসলে VPS-এর কতটা বিশ্বাস করছেন।

FAQ

মিল থাকা checksum কি download নিরাপদ হওয়ার প্রমাণ?

না। এর অর্থ হলো, আপনার কাছে থাকা bytes যে digest-এর সঙ্গে তুলনা করেছেন, তার সঙ্গে মিলে গেছে। যে attacker digest প্রকাশকারী page নিয়ন্ত্রণ করে, সে নিজের file-এর digest প্রকাশ করতে পারে, এবং আপনার check OK দেখাবে। মিল থাকা শুধু consistency-এর দাবি। নিরাপত্তার দাবি করতে হলে অন্য একটি source থেকে সংগ্রহ করা key দিয়ে signature যাচাই করতে হবে। তারপরই digest সেই key-এর ওপর থাকা trust পায়।

sha256sum -c কেন FAILED open or read দেখায়?

কারণ এটি file পড়েনি। তার ঠিক আগের আলাদা line-এ No such file or directory এবং যে নামটি এটি খুঁজেছে তা বলা আছে। SHA256SUMS file-এর নামগুলো আপনি যে directory-তে command চালান, তার relative path হিসেবে গণ্য হয়। তাই download থাকা directory-তে যান এবং command আবার চালান। তালিকায় download না করা file-এর নামও থাকলে --ignore-missing যোগ করুন। কোনো open or read ছাড়া সাধারণ FAILED সম্পূর্ণ বিপরীত পরিস্থিতি বোঝায়: file পড়া হয়েছে, কিন্তু তার digest মেলেনি।

Download যাচাইয়ের জন্য MD5 কি যথেষ্ট?

অনিচ্ছাকৃত ক্ষতির ক্ষেত্রে, হ্যাঁ। অসম্পূর্ণ transfer বা disk-এর ত্রুটিপূর্ণ block কাকতালীয়ভাবে মিলে যাওয়া MD5 digest তৈরি করবে না। Attacker-এর বিরুদ্ধে, না। একই MD5 digest-যুক্ত দুটি ভিন্ন file 2004 সাল থেকেই তৈরি করা সম্ভব, এবং 2020 সালে SHA-1-এর chosen-prefix collision দেখানো হয়েছে। কোনো project MD5 এবং SHA-256 দুটোই প্রকাশ করলে SHA-256 line ব্যবহার করুন। শুধু MD5 ব্যবহারকারী project-কে পুরোনো release process-এর লক্ষণ হিসেবে বিবেচনা করুন।

sha256sum -c এবং gpg --verify-এর মধ্যে পার্থক্য কী?

sha256sum -c প্রমাণ করে যে একটি file কোনো digest-এর সঙ্গে মিলে। gpg --verify প্রমাণ করে যে একটি digest file নির্দিষ্ট private key-এর holder দ্বারা signed হয়েছে। এগুলো ভিন্ন প্রশ্নের উত্তর দেয়। তাই কোনো project দুটোই দিলে উভয় check চালান। Signature digest list-কে trustworthy করে, আর digest list download করা file-কে trustworthy করে।

Web page-এ প্রকাশিত digest দিয়ে একটি file কীভাবে যাচাই করব?

চোখে দেখে characters তুলনা করবেন না। একই line-এ digest এবং file name লিখুন, এবং তাদের মধ্যে দুইটি space রাখুন। এরপর ওই file-এর বিরুদ্ধে sha256sum -c চালান এবং এটি যে OK বা FAILED দেখায় তা পড়ুন। printf '%s %s\n' দিয়ে line তৈরি করলে formatting-এর ভুল এড়ানো যায়। এসব ভুলের কারণে sha256sum file-টি no properly formatted checksum lines found দিয়ে reject করতে পারে।