Чому слухач зворотного SSH-проксі доступний лише на сервері
Перевірте адресу прив'язки віддаленого слухача та режим GatewayPorts, перш ніж змінювати протокол проксі або облікові дані.
Віддалене переспрямування може працювати з SSH-сервера, але відхиляти підключення з іншої машини, оскільки слухає лише на loopback. Спершу перевірте фактичну адресу прослуховування.
На боці сервера GatewayPorts | Прив'язка віддаленого переспрямування |
|---|---|
no, типово | Обмежує слухачів loopback |
yes | Примусово прив'язує до всіх адрес (wildcard) |
clientspecified | Дозволяє клієнту запитати конкретну адресу прив'язки |
Для слухача, призначеного для одного контрольованого інтерфейсу, сервер може використовувати:
GatewayPorts clientspecifiedДалі клієнт запитує відповідну адресу у своїй специфікації -R. Ця адреса має існувати на віддаленій машині, а інші обмеження переспрямування все ще діють. Клієнтський -g не є взаємозамінним керуванням для цього напрямку.
Три дозволи залишаються окремими: авторизація SSH на створення переспрямування, мережевий доступ до його слухача та власна політика доступу служби HTTP або SOCKS. Вхід по SSH автентифікує творця тунелю; він не автентифікує кожного наступного викликача спільного слухача і не додає запит пароля SOCKS.
Якщо віддалений викликач усе ще не може підключитися, перевірте в цьому порядку адресу прив'язки, обмеження переспрямування сервера та шлях через брандмауер. Після того як TCP досягне слухача, невдале рукостискання проксі є пізнішою проблемою.