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 و امید به اینکه ترابرد دوم متوجه شود.