OpenSSH no Windows sempre vincula soquetes usados ​​para encaminhamento remoto ao LOOPBACK

OpenSSH no Windows sempre vincula soquetes usados ​​para encaminhamento remoto ao LOOPBACK

Como diz o título.

O Host A atua como um servidor (bastion-host, chame-o como quiser).

Agora, o host B executa:

ssh -R 2222:localhost:22 usuário@A

como resultado, um soquete TCP é gerado em A, mas está vinculado a 2222@Loopbackou seja, impedindo conexões remotas com ele.

Como alterar 127.0.0.1 para 0.0.0.0ou qualquer outra coisamais sensato?

Responder1

Está faltando a bind_addressparte opcional da -Respecificação. Nosshdocumentação(conforme vinculado porMicrosoft) ele escreve,

Por padrão, os soquetes de escuta TCP no servidor serão vinculados apenas à interface de loopback. Isso pode ser substituído especificando um arquivo bind_address. Um vazio bind_address, ou o endereço *, indica que o soquete remoto deve escutar em todas as interfaces. A especificação de um controle remoto bind_addresssó terá sucesso se a opção do servidor GatewayPortsestiver habilitada (vejasshd_config(5)).

Você está usando a versão de três tuplas do parâmetro, mas precisa da versão de quatro tuplas:

-R port:host:hostport
-R [bind_address]:port:host:hostport

Portanto, para permitir que qualquer pessoa se conecte à porta de escuta no servidor remoto, você precisa garantir que GatewayPortsela esteja habilitada no servidorsshd_config euse uma variação de comando como esta:

ssh -R :2222:localhost:22 user@A

Os dois pontos iniciais ( :) também implicam um curinga asterisco inicial que permite conexões de qualquer lugar. Pessoalmente acho que esta versão com curinga deixa mais claro que o que está escrito é intencional:

ssh -R *:2222:localhost:22 user@A

informação relacionada