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 والأمل في أن يلاحظ الناقل الثاني ذلك.