ทำไมตัวรับฟังพร็อกซี SSH แบบย้อนกลับจึงเข้าถึงได้เฉพาะบนเซิร์ฟเวอร์
ตรวจสอบที่อยู่ bind ของตัวรับฟังระยะไกลและโหมด GatewayPorts ก่อนเปลี่ยนโปรโตคอลพร็อกซีหรือข้อมูลรับรอง
การส่งต่อระยะไกลอาจทำงานจากเซิร์ฟเวอร์ SSH ได้แต่ปฏิเสธการเชื่อมต่อจากเครื่องอื่นเพราะรับฟังบน loopback เท่านั้น ตรวจสอบที่อยู่รับฟังจริงก่อน
ฝั่งเซิร์ฟเวอร์ GatewayPorts | bind ของการส่งต่อระยะไกล |
|---|---|
no, ค่าเริ่มต้น | จำกัดตัวรับฟังให้อยู่บน loopback |
yes | บังคับ bind แบบ wildcard |
clientspecified | อนุญาตให้ไคลเอนต์ขอที่อยู่ bind ที่เจาะจง |
สำหรับตัวรับฟังที่ตั้งใจไว้บนอินเทอร์เฟซที่ควบคุมได้หนึ่งเดียว เซิร์ฟเวอร์สามารถใช้:
GatewayPorts clientspecifiedจากนั้นไคลเอนต์จะขอที่อยู่ที่เหมาะสมในข้อกำหนด -R ของตน ที่อยู่นั้นต้องมีอยู่บนเครื่องระยะไกล และข้อจำกัดการส่งต่ออื่นยังคงใช้บังคับ -g ฝั่งไคลเอนต์ไม่ใช่การควบคุมที่ใช้แทนกันได้สำหรับทิศทางนี้
สิทธิ์สามอย่างยังแยกจากกัน: การอนุญาต SSH เพื่อสร้างการส่งต่อ การเข้าถึงเครือข่ายไปยังตัวรับฟัง และนโยบายการเข้าถึงของบริการ HTTP หรือ SOCKS เอง การเข้าสู่ระบบ SSH รับรองผู้สร้างอุโมงค์ แต่ไม่ได้รับรองผู้เรียกใช้ตัวรับฟังที่แชร์ในภายหลังทุกคน และไม่ได้เพิ่มการท้าทายรหัสผ่าน SOCKS
หากผู้เรียกใช้ระยะไกลยังเชื่อมต่อไม่ได้ ให้ตรวจสอบที่อยู่ bind ข้อจำกัดการส่งต่อของเซิร์ฟเวอร์ และเส้นทางไฟร์วอลล์ตามลำดับนั้น เมื่อ TCP ไปถึงตัวรับฟังแล้ว การจับมือพร็อกซีที่ล้มเหลวเป็นปัญหาภายหลัง