يمكن لحساب SSH وكيلي أن يعمل دون صدفة

الإعداد المغري هو AllowTcpForwarding no. للأسف، يعطّل أيضًا إعادة التوجيه التي يحتاجها وكيل SSH SOCKS محلي. إعادة التوجيه الديناميكي ليست ثغرة تلتف على سياسة الخادم.

بالنسبة إلى حساب مخصص، يفصل OpenSSH بين عدة قدرات. يمكن لمقتطف سياسة أن يسمح بإعادة التوجيه المحلي مع منع جلسات الصدفة والنظم الفرعية:

Match User proxyuser
    AllowTcpForwarding local
    MaxSessions 0
    PermitTTY no
    X11Forwarding no
    AllowAgentForwarding no

يصف دليل الخادم MaxSessions 0 بأنه يمنع جلسات الصدفة وتسجيل الدخول والنظم الفرعية مع السماح بإعادة التوجيه. أدمج هذا في حساب موثَّق قائم؛ فهو ليس إعدادًا أمنيًا كاملًا لـ SSH.

إعادة التوجيه وحدها ليست SOCKS وحدها

يمكن أن يطلب توجيه محلي ثابت وطلب SOCKS في النهاية من الخادم اتصال وجهة من النوع نفسه. السماح بإعادة التوجيه المحلي لا يضمن أن العميل استخدم واجهة SOCKS معينة. لا تصف الحساب بأنه يفرض استخدام SOCKS وحده.

يستطيع PermitOpen تقييد أزواج المضيف والمنفذ للوجهة عندما تناسب قائمة محددة المتطلب. وهو ليس حظرًا عامًا واعيًا بتحليل أسماء المضيفين على كل شبكة خاصة. قد تحتاج قيود العناوين الأوسع إلى سياسة شبكة مضيف مناسبة.

يمكن لإعدادات الحساب والمفتاح وإعدادات الخادم المضمّنة أن تقيّد إعادة التوجيه أكثر. وقد يزيل حظر شامل لإعادة التوجيه في مكان آخر قدرة يبدو أن هذا المقتطف يسمح بها.

استخدم إجراء إدارة الخادم المعتاد مع مسار استرداد، ثم قيّم القدرات المسموح بها والممنوعة كلًا على حدة. النتيجة المقصودة أذونات إعادة توجيه صريحة، لا تسجيل دخول تفاعلي تُرك متاحًا عن غير قصد ولا وكيل عُطّل بفعل قيده الخاص.