Por que um ouvinte de proxy SSH reverso só é acessível no servidor
Verifique o endereço de bind do ouvinte remoto e o modo GatewayPorts antes de alterar o protocolo do proxy ou as credenciais.
Um encaminhamento remoto pode funcionar a partir do servidor SSH mas recusar conexões de outra máquina porque escuta apenas em loopback. Verifique primeiro o endereço de escuta real.
No lado do servidor GatewayPorts | Bind do encaminhamento remoto |
|---|---|
no, o padrão | Restringe os ouvintes a loopback |
yes | Força o bind com wildcard |
clientspecified | Permite ao cliente solicitar um endereço de bind específico |
Para um ouvinte destinado a uma interface controlada, o servidor pode usar:
GatewayPorts clientspecifiedO cliente então solicita um endereço adequado na sua especificação -R. Esse endereço deve existir na máquina remota, e as demais restrições de encaminhamento continuam valendo. O -g do lado do cliente não é um controle intercambiável para esta direção.
Três permissões permanecem distintas: a autorização SSH para criar o encaminhamento, o acesso de rede ao seu ouvinte e a política de acesso do próprio serviço HTTP ou SOCKS. Um login SSH autentica o criador do túnel; não autentica cada chamador posterior de um ouvinte compartilhado nem acrescenta um desafio de senha SOCKS.
Se um chamador remoto ainda não conseguir conectar, inspecione o endereço de bind, as restrições de encaminhamento do servidor e o caminho do firewall nessa ordem. Depois que o TCP chega ao ouvinte, um handshake de proxy com falha é um problema posterior.