auth-nocache ও ক্রেডেনশিয়াল ফাইল: উপকার করে না ক্ষতি?
auth-nocache চাওয়া ক্রেডেনশিয়াল মেমরি থেকে মুছে ফেলে। পাসওয়ার্ড ফাইলে থাকলে সতর্কবার্তার অর্থ কমে যায়, আর অপশনটি পুনরায় সমঝোতা ভেঙে দিতে পারে।
OpenVPN চালু হওয়ার সময় এমন একটি সতর্কবার্তা ছাপে যা পরামর্শ দেয় auth-nocache, আর লোভনীয় প্রতিক্রিয়া হলো অপশনটি যোগ করে লাইনটি হারিয়ে যাওয়া দেখা। এই পরামর্শ ধরে নেয় ইন্টারঅ্যাকটিভ লগইন। ব্যবহারকারীর নাম ও পাসওয়ার্ড ফাইলে চলে গেলে তুলনাটি বদলে যায়: অপশনটি টেকসই কপিটি রক্ষা করা বন্ধ করে, আর সুবিধা ছাড়া ক্লায়েন্টে এটি পরে পুনরায় সমঝোতা ভাঙতে পারে। প্রোফাইল সম্পাদনার আগে দুটি স্টোরেজ মডেল আলাদা রাখা দরকার।
ক্রেডেনশিয়াল অনুরোধের দুটি উত্তর
প্রথম মডেল হলো একজন মানুষ টার্মিনালে ক্রেডেনশিয়াল টাইপ করছে, বা একটি ম্যানেজমেন্ট ইন্টারফেস সেশনটির জন্য তা ধরে রাখছে। OpenVPN ওই কপিটি রাখে যাতে পরের পুনরায় সমঝোতায় আবার না জিজ্ঞাসা করেই উত্তর দিতে পারে, আর সতর্কবার্তাটি ঠিক সে বিষয়েই। ডিস্কে কিছুই জড়িত নয়, তাই রক্ষা করার একমাত্র জিনিস হলো মানটি ধরে রাখা প্রক্রিয়াটি। ক্লায়েন্ট বন্ধ করলে কপিটিও তার সঙ্গে চলে যায়।
দ্বিতীয় মডেল হলো ফাইলের দিকে নির্দেশ করা auth-user-pass , যেখানে ফাইলটিই ভাণ্ডার এবং মান দরকার হলে ক্লায়েন্ট তা পড়ে। এখানে গুরুত্বপূর্ণ ঝুঁকি প্রক্রিয়ার মেমরি নয়, বরং ওই ফাইলের অনুমতি ও মালিকানা। চালুর সতর্কবার্তাটি কনফিগের নির্দেশ থেকেই আসে, আপনি পাসওয়ার্ড কীভাবে দেন তার পরীক্ষা থেকে নয়, তাই এটি দুই মডেলেই আসে এবং কোনোটিকেই নির্দেশ করে না।
এই তুলনার বাকিটা ওই বিভাজন থেকেই আসে: এক মডেলের জন্য মেমরি ব্যবস্থাপনা, অন্যটির জন্য ফাইল ব্যবস্থাপনা ও প্রক্রিয়ার পরিচয়।
auth-nocache আসলে কী বাদ দেয়
ইন্টারঅ্যাকটিভ লগইনে --auth-nocache ব্যবহারের পর সংরক্ষিত কপিটি মেমরি থেকে সরিয়ে দেয়। খরচ হলো প্রতিটি পুনরায় সমঝোতার ব্যবধানে নতুন অনুরোধ, কারণ পরের রাউন্ড বাদ দেওয়া জিনিস পুনরায় ব্যবহার করতে পারে না।
ফাইলভিত্তিক লগইনে ক্লায়েন্ট ফাইলটি আবার পড়তে পারে, তাই বাদ দেওয়াটি বেশিরভাগ ক্ষেত্রে অদৃশ্য। এটি দৃশ্যমান হয় সেই এক জায়গায় যেখানে মানুষ তা আশা করে না: ডেমন সুবিধা ছাড়ার পর, যদি ক্রেডেনশিয়াল ফাইলটি এখন যে অ্যাকাউন্টে চলছে তা পড়তে না পারে।
এই বিনিময়টি বোঝেন বলেই অপশনটি যোগ করুন, সতর্কবার্তা দেখা গেল বলে নয়। লগ শান্ত করার জন্য যোগ করা অপশন এমন অপশন যার প্রভাব কেউ মাপেনি।
ফাইলভিত্তিক পথ কোথায় ভাঙে
যে ক্লায়েন্ট টানেল ডিভাইস খুলতে root হিসেবে শুরু করে তারপর user এবং group -এ বদলে যায়, সে ক্রেডেনশিয়াল ফাইলটি দুবার পড়ে: বদলের আগে একবার, তার পরের পুনরায় সমঝোতায় একবার। ফাইলটি মোড 600 এবং root-এর মালিকানায় থাকলে দ্বিতীয় পড়াটি ব্যর্থ হয়, আর ব্যর্থতাটি এক ঘণ্টা পরে সার্ভারের সমস্যার মতো দেখতে একটি প্রমাণীকরণ ত্রুটি হিসেবে দেখা যায়। পুনরায় সমঝোতার ব্যবধানের আশপাশে ক্লায়েন্ট লগ দেখুন, তারপর অ্যাকাউন্ট ও ফাইল একসঙ্গে দেখুন।
stat -c '%a %U:%G' /etc/openvpn/client.creds
ps -o user:12,args -C openvpn | headদুটি লাইনই গুরুত্বপূর্ণ। প্রথমটি বলে কে ফাইলটি পড়তে পারে, দ্বিতীয়টি বলে চলমান ডেমনটি আসলে কে, আর এদের মধ্যে অমিল এমন ব্যর্থতা ব্যাখ্যা করে যা পাসওয়ার্ড যতবারই নতুন করে লিখুন ঠিক হবে না।
ব্যবহারিক সমাধান অনাড়ম্বর: ফাইলটি এমন ডিরেক্টরি ও মালিকের কাছে সরান যা ডেমনের অ্যাকাউন্ট পড়তে পারে, অথবা বিশেষাধিকারপ্রাপ্ত পাঠ ধরে রাখুন এবং নিশ্চিত করুন আপনার ক্লায়েন্ট একবারই পড়ে। ফাইলটি সবার জন্য পাঠযোগ্য করে সমস্যাটি সমাধান করবেন না।
যে ক্ষেত্রে সত্যিই অপশনটি দরকার
এককালীন কোডসহ লগইন auth-nocache ভিন্ন কারণে চায়। এককালীন কোড প্রথম প্রমাণীকরণেই খরচ হয়ে যায়, তাই ক্যাশে করা কপি পরের পুনরায় সমঝোতায় অকেজো, আর পুরোনো মান আবার চালুও হতে পারে।
এটি ক্রেডেনশিয়ালের ধরন নিয়ে প্রশ্ন, এটি কোথায় সংরক্ষিত তা নিয়ে নয়। সুরক্ষিত ফাইলের স্থির পাসওয়ার্ডের বৈশিষ্ট্য উল্টো: প্রতিটি পুনরায় সমঝোতায় তা পাঠযোগ্য হতে হবে, আর যে সুরক্ষা দরকার তা ফাইলের ওপর।
এই দুই কারণ প্রোফাইল মন্তব্যে আলাদা রাখুন, নইলে পরের প্রশাসক ধরে নেবেন অপশনটি তাঁর নিজের বেছে নেওয়া কারণেই আছে।
এক সিদ্ধান্তে তুলনা
মানুষ উপস্থিত থাকলে এবং সতেজতা গুরুত্বপূর্ণ হলে ইন্টারঅ্যাকটিভ মডেল বেছে নিন, আর বারবার অনুরোধকে তার খরচ হিসেবে মেনে নিন। ক্লায়েন্ট তদারকি ছাড়া চললে ফাইল মডেল বেছে নিন, আর পরিশ্রম মালিকানা, মোড ও বিশেষাধিকার ত্যাগে লাগান।
কোনো মডেলই সংরক্ষিত পাসওয়ার্ডকে একা নিরাপদ করে না, আর কোনোটিই চালুর সতর্কবার্তাকে অর্থবহ করে না।
সতর্কবার্তাই যদি প্রোফাইল খোলার একমাত্র কারণ হয়, তবে অস্পষ্ট অপশন নয়, সিদ্ধান্তটি লিখে রাখুন: ক্রেডেনশিয়াল আসে এমন ফাইল থেকে যা ডেমনের অ্যাকাউন্ট পড়তে পারে, পুনরায় সমঝোতা সফল হতে দেখা গেছে, এবং ব্যবধান বদলানোর আগে OpenVPN 2.6 ম্যানুয়ালের পুনরায় সমঝোতা অংশ পড়া হয়েছে। ওই টীকা যেকোনো একক ফ্ল্যাগের চেয়ে বেশি দিন টেকে।