অবিশ্বস্ত VPN-এ আপনার SSH পাসওয়ার্ড আসলে কে দেখে?

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

কিছু লেখার আগেই প্রাপককে নাম দিন

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

দুটি দিক আলাদা রাখুন মাথায়। হোস্ট কি উত্তর দেয় আপনি কোন সার্ভারে পৌঁছেছেন। পাসওয়ার্ড বা কি প্রমাণীকরণ উত্তর দেয় সার্ভার কোন ব্যবহারকারীকে গ্রহণ করে। দ্বিতীয়টির উন্নতি প্রথমটিকে কখনো সারায় না।

হোস্টের পরিচয়, রেকর্ড ও আলোচনা যাচাই করুন

ক্লায়েন্টে শুরু করুন আপনার কাছে আগে থেকেই থাকা রেকর্ড দিয়ে। প্রকাশিত ফিঙ্গারপ্রিন্ট যা একটি বিশ্বস্ত উৎসের সঙ্গে মিলিয়ে দেখা হয়, আর known_hosts-এর এমন এন্ট্রি যা এখনো মেলে, প্রমাণীকরণ শুরুর আগে আপনাকে একমাত্র প্রয়োজনীয় প্রমাণ দেয়।

ssh-keygen -F ssh.internal.example.net -f ~/.ssh/known_hosts
ssh -o StrictHostKeyChecking=yes ssh.internal.example.net

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

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
sudo sshd -T | grep -E 'hostkey|kexalgorithms|cipher'

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

সার্ভার সত্যিই কোন পদ্ধতিগুলো গ্রহণ করে তা পড়ুন

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

sudo sshd -T | grep -E 'passwordauthentication|pubkeyauthentication|permitrootlogin'

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

হোস্ট-কি সতর্কতাকে ঘটনার ধাপ হিসেবে সামলান

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

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

এই রানবুক কী ঢাকে না

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

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