چرا شنوندهٔ پروکسی SSH معکوس فقط روی سرور قابل دسترسی است
پیش از تغییر پروتکل پروکسی یا اعتبارنامه‌ها، نشانی اتصال شنوندهٔ راه‌دور و حالت GatewayPorts را بررسی کنید.
ارسال راه‌دور می‌تواند از سرور SSH کار کند اما اتصال‌های ماشین دیگری را رد کند، چون فقط روی loopback گوش می‌دهد. نخست نشانی واقعی شنونده را بررسی کنید.
در سمت سرور GatewayPorts | اتصال ارسال راه‌دور |
|---|---|
no، مقدار پیش‌فرض | شنونده‌ها را به loopback محدود می‌کند |
yes | اتصال wildcard را تحمیل می‌کند |
clientspecified | به کارخواه اجازه می‌دهد نشانی اتصال مشخصی درخواست کند |
برای شنونده‌ای که برای یک واسط کنترل‌شده در نظر گرفته شده است، سرور می‌تواند استفاده کند از:
GatewayPorts clientspecifiedسپس کارخواه نشانی مناسب را در مشخصات -R خود درخواست می‌کند. آن نشانی باید روی ماشین راه‌دور وجود داشته باشد و دیگر محدودیت‌های ارسال همچنان اعمال می‌شوند. گزینهٔ -g در سمت کارخواه جایگزین قابل‌تبادلی برای این جهت نیست.
سه مجوز از هم جدا می‌مانند: مجوز SSH برای ساختن ارسال، دسترسی شبکه به شنوندهٔ آن، و سیاست دسترسی خود سرویس HTTP یا SOCKS. ورود SSH سازندهٔ تونل را احراز هویت می‌کند؛ اما هر فراخوان بعدی یک شنوندهٔ مشترک را احراز نمی‌کند و چالش گذرواژهٔ SOCKS اضافه نمی‌کند.
اگر فراخوان راه‌دور هنوز نمی‌تواند متصل شود، به همین ترتیب نشانی اتصال، محدودیت‌های ارسال سرور و مسیر دیوار آتش را بررسی کنید. پس از آنکه TCP به شنونده رسید، دست‌دادن ناموفق پروکسی مسئلهٔ بعدی است.