SSH এজেন্ট ফরওয়ার্ডিং বনাম কী কপি করা: আসলে কী ফাঁস হয়

দুটি ভিন্ন ঘটনাকে ফাঁস হওয়া SSH কী বলা হয়, আর তাদের প্রতিক্রিয়াও ভিন্ন। পাবলিক-কী প্রমাণীকরণ একটি পাবলিক কী এবং প্রাইভেট কী দিয়ে তৈরি স্বাক্ষর পাঠায়, তাই প্রাইভেট কী কখনোই অনুরোধের কোনো ফিল্ড হয় না। এজেন্ট ফরওয়ার্ডিং অন্য কিছু উন্মুক্ত করে, কারণ আপনার ফরওয়ার্ড করা এজেন্টে পৌঁছাতে পারে এমন দূরবর্তী হোস্ট কী না রেখেই তাকে স্বাক্ষর করতে বলতে পারে। এই দুটিকে এক ঘটনা ধরলে হয় অপ্রয়োজনীয় কী পরিবর্তন হয়, নয়তো একটি ডেলিগেশন চালু থেকে যায়।

পাবলিক-কী লগইন কী নয়, স্বাক্ষর পাঠায়

প্রমাণীকরণের বিনিময় ব্যবহারকারীর পাবলিক কী এবং সেশন ডেটার ওপর একটি স্বাক্ষর বহন করে। সার্ভার সেই স্বাক্ষর যাচাই করে যে কী-তে সে আগেই আস্থা রাখে, তাই অবিশ্বস্ত নেটওয়ার্ক জুড়েও প্রাইভেট অংশ ক্লায়েন্টে থাকতে পারে। টানেল দেখতে থাকা VPN অপারেটর যেভাবেই হোক একটি এনক্রিপ্টেড SSH সেশন দেখে।

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

ssh-keygen -lf ~/.ssh/id_ed25519.pub
ssh -o StrictHostKeyChecking=yes [email protected]

প্রথম কমান্ডটি পাবলিক ফিঙ্গারপ্রিন্ট ছাপে, যাতে আপনি সার্ভারের তালিকার সঙ্গে মিলিয়ে দেখতে পারেন। দ্বিতীয়টি কোনোদিন কেউ না পড়া ডিফল্টের ওপর ভরসা না করে হোস্ট-কী যাচাইকে স্পষ্ট করে। কী নিয়ে কিছু বদলানোর আগে দুটিই চালান, যাতে ভিত্তিরেখা নথিভুক্ত থাকে।

এজেন্ট ফরওয়ার্ডিং স্বাক্ষর করার ক্ষমতা অর্পণ করে

ফরওয়ার্ডিং চালু থাকলে দূরবর্তী হোস্টে একটি সকেট দেখা যায় এবং স্থানীয় এজেন্ট তার মধ্য দিয়ে আসা অনুরোধের উত্তর দেয়। সেশনের সময় ওই সকেট ব্যবহার করতে পারে এমন যে কেউ যে হোস্টগুলো লোড করা পরিচয় গ্রহণ করে, সেখানে আপনার হয়ে প্রমাণীকরণ করতে পারে। এটি কাজ করাতে কোনো প্রাইভেট কী নেটওয়ার্ক পেরোয় না।

ক্ষমতাটাই এখানে ঝুঁকি, ফাইল নয়। তাই ফরওয়ার্ডিং একটি নাম দেওয়া কাজ ও নাম দেওয়া হোস্টের জন্য, ল্যাপটপের প্রতিটি সংযোগের জন্য নয়। যে জাম্প হোস্ট ফরওয়ার্ড করা এজেন্ট ছাড়াই সংযোগটি রিলে করে, সে সাধারণত প্রয়োজনটাই পুরোপুরি সরিয়ে দেয়।

ssh-add -l
ssh -o ForwardAgent=no [email protected]
ssh -J [email protected] [email protected]

প্রথমটি দেখায় এজেন্ট এই মুহূর্তে কোন কোন পরিচয় ধরে আছে, যা অন্য মেশিনকে এর সকেট দেওয়ার আগে জানা দরকার। দ্বিতীয়টি ডেলিগেশন ছাড়াই সংযোগ করে। তৃতীয়টি জাম্প হোস্টের সেই ধরনটি দেখায় যা প্রায়ই ফরওয়ার্ডিংকে পুরোপুরি প্রতিস্থাপন করে।

আপনার কাছে থাকা প্রমাণ থেকে প্রতিক্রিয়া বেছে নিন

যে স্বাক্ষরকারী পরিচয় উন্মুক্ত হয়েছে বলে মনে করা হয়, তার জন্য কী প্রতিস্থাপন ও বাতিলের প্রক্রিয়া দরকার, এবং যে সেবাগুলো তাকে বিশ্বাস করত সেখান থেকে তার গ্রহণযোগ্যতা সরানো দরকার। ল্যাপটপে থাকা কপিটি মুছলে অন্য প্রতিটি কপি অক্ষতই থাকে। সেবাগুলো থেকে শুরু করুন, পরে ক্লায়েন্টগুলো পরিষ্কার করুন।

সাময়িক ডেলিগেশন সমস্যা আরও সংকীর্ণ। যে ফরওয়ার্ডিং দরকার ছিল না তা বন্ধ করুন, এবং ঘটনার মালিকের সঙ্গে দেখুন এটি কোন সেশন ও পরিচয়কে জুড়ে ছিল। কী প্রতিস্থাপন পরেও আসতে পারে, কিন্তু সেটি ঠিক করে প্রমাণ, দুশ্চিন্তা নয়।

কোনো রপ্তানি দেখা না যাওয়া কেবল প্রমাণ করে যে আপনি যে প্রক্রিয়াটিকে ভয় পেয়েছিলেন সেটি দেখা যায়নি। ওই সকেটের অন্য প্রান্তের হোস্ট আর কী করতে পারত, সে সম্পর্কে এটি কিছুই বলে না।

প্রতিবেদনে নিয়ন্ত্রণগুলো আলাদা রাখুন

প্রাইভেট উপাদান রক্ষা করুন, কে এর কাছে স্বাক্ষর চাইতে পারবে তা সীমিত করুন, যাচাই করা সমকক্ষ পরিচয় ধরে রাখুন। এগুলো তিনটি নিয়ন্ত্রণ যা একে অন্যকে শক্তিশালী করে, এবং কী ঘটেছে তা ব্যাখ্যা করার সময় এর কোনোটিই অন্যটির বিকল্প নয়।

নিরাপত্তা ভঙ্গ হওয়া ল্যাপটপ বা তার ওপর একটি বিশেষাধিকারপ্রাপ্ত অ্যাপ্লিকেশন অনেক বিস্তৃত প্রভাবের তৃতীয় ঘটনা। VPN রুট বদলালে সেটি মেটে না, আর ডিস্ক থেকে পড়া হয়ে থাকতে পারে এমন কী-র ওপর আস্থাও ফেরে না।

কোন উপাদানে আস্থা রাখা হয়েছিল, ফরওয়ার্ডিং চালু ছিল কি না, এবং আসলে কী দেখা গেছে তা লিখে রাখুন। সেই নথিই ফাঁস মানে কী, এমন অনুমানের বদলে পরের সিদ্ধান্তকে যুক্তিসঙ্গত করে।