MaxSessions, MaxStartups নাকি নিবন্ধন: কোন SSH সীমা বেছে নেবেন

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

প্রতিটি অপশন আসলে কী গোনে

MaxSessions একটি প্রমাণীকৃত নেটওয়ার্ক সংযোগের বহন করা খোলা সেশনের সংখ্যা সীমিত করে। এখানে সেশন মানে একটি শেল, একটি exec অনুরোধ, SFTP-এর মতো একটি সাবসিস্টেম, বা একটি SSH ট্রান্সপোর্টের ভেতরে মাল্টিপ্লেক্স করা অনুরূপ চ্যানেল। দ্বিতীয় ssh আহ্বান একটি দ্বিতীয় ট্রান্সপোর্ট খোলে, আবার প্রমাণীকরণ করে এবং নিজের অনুমতি পায়। প্রথম সংযোগের সেশন সংখ্যা এর জন্য অপ্রাসঙ্গিক।

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

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

কোথায় MaxSessions আর কোটা থাকে না

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

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

আপনি যা লোড হয়েছে ভাবেন সেই ফাইলের বদলে কার্যকর কনফিগারেশনটি ডাম্প করুন। ইনক্লুড ও drop-in ডিরেক্টরির অর্থ প্রায়ই হলো কার্যকর মানটি আপনি সম্পাদনা করা মান নয়।

MaxStartups গ্রাহককে নয়, ডেমনকে রক্ষা করে

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

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

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

প্রতি-ব্যবহারকারী স্লটের ভাগ করা অবস্থা দরকার

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

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

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

দুটি বাস্তব সংযোগ দিয়ে নীতি যাচাই করুন

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

আগে কার্যকর সীমাগুলো পড়ুন, তারপর নীতির প্রত্যাখ্যান করার কথা এমন সংযোগগুলো খুলুন। সেই পরীক্ষার দুই অর্ধই গুরুত্বপূর্ণ, এবং কোনোটিই অন্যটির বিকল্প নয়।

sshd -T | grep -iE "maxsessions|maxstartups|allowtcpforwarding|permitopen"
ss -tn state established '( sport = :22 )' | head
ssh -N -L 8080:127.0.0.1:80 [email protected]

দুটি টার্মিনালে টানেল কমান্ডটি দুবার চালান এবং পোর্ট 22-এ প্রতিষ্ঠিত সংযোগগুলো গোনেন। যদি আপনার নীতি এক সক্রিয় ট্রান্সপোর্ট দাবি করার সময় দুটোই ট্রাফিক বহন করে, তবে নীতি প্রয়োগ নয়, নথি। এই ফাঁকটি প্রবেশ স্তরে ঠিক করুন, MaxSessions কমিয়ে দ্বিতীয় ট্রান্সপোর্ট লক্ষ্য করবে বলে আশা করে নয়।