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 کم کر کے یہ امید کرنے سے نہیں کہ دوسرا ٹرانسپورٹ نوٹس کرے گا۔