Por qué un oyente de proxy SSH inverso solo es accesible en el servidor
Compruebe la dirección de enlace del oyente remoto y el modo GatewayPorts antes de cambiar el protocolo del proxy o las credenciales.
Un reenvío remoto puede funcionar desde el servidor SSH pero rechazar conexiones de otra máquina porque solo escucha en loopback. Compruebe primero la dirección real del oyente.
En el lado del servidor GatewayPorts | Enlace del reenvío remoto |
|---|---|
no, el valor predeterminado | Restringe los oyentes a loopback |
yes | Fuerza el enlace comodín (wildcard) |
clientspecified | Permite al cliente solicitar una dirección de enlace concreta |
Para un oyente destinado a una interfaz controlada, el servidor puede usar:
GatewayPorts clientspecifiedDespués, el cliente solicita una dirección adecuada en su especificación -R. Esa dirección debe existir en la máquina remota y las demás restricciones de reenvío siguen aplicándose. El -g del lado del cliente no es un control intercambiable para esta dirección.
Tres permisos siguen siendo distintos: la autorización SSH para crear el reenvío, el acceso de red a su oyente y la política de acceso propia del servicio HTTP o SOCKS. Un inicio de sesión SSH autentica al creador del túnel; no autentica a cada llamador posterior de un oyente compartido ni añade un desafío de contraseña SOCKS.
Si un llamador remoto sigue sin poder conectarse, inspeccione la dirección de enlace, las restricciones de reenvío del servidor y la ruta del cortafuegos en ese orden. Una vez que TCP llega al oyente, un fallo de negociación del proxy es un problema posterior.