SSH: Resolução de problemas de erros “Falha no encaminhamento de porta remota para porta de escuta”

Pergunta: Por que ssh -N -R 2222:localhost:22 <bluehost_user>@<bluehost_ip> resultar em um erro "Encaminhamento de porta remoto falhou para a porta de escuta"? O objetivo é estabelecer um túnel reverso com o encaminhamento de porta para consistentemente ssh em um host atrás de um roteador NAT que tenha um IP privado dinâmico. Veja a imagem para detalhes.

Já tentou:

Pesquisou a literatura existente sobre o Google, Stackoverflow, etc. Existem tópicos relativos a esta mensagem de erro, no entanto as resoluções dadas resolvem causas raiz diferentes daquela desta instância particular porque essas resoluções não resolvem o erro neste caso.
Eu realizei vários diagnósticos para validar as portas necessárias estão abertas. Alguns desses resultados são mostrados na imagem abaixo.

Túnel SSH reverso

Atualizar

Eu estava tentando o seguinte comando para o Passo 2: reduser@redhost:~ ssh greenuser@greenhost -p 2222

Deveria ser: reduser@redhost:~ ssh greenuser@bluehost -p 2222 Você deseja usar as credenciais de usuário verde no IP bluehost porque o host no qual você está efetuando quando você usa a porta 2222 é realmente o host verde.

— ngm_code
fonte

Você fez check-out serverfault.com/questions/595323/… ?

— balwa

@balwa Verificado, mas trata-se de conexões que expiram após um período de tempo. A conexão nunca é bem-sucedida no meu caso. Eu também faço uso dos parâmetros KeepAliveInterval para que haja controle explícito sobre alguns dos fatores de tempo.

— ngm_code

@ModeratorImpersonator tentou ssh -N -R <bluehost_ip>:2222:localhost:22 e ssh pareceu levar isso como sintaxe inválida. ssh simplesmente retornou

usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]            [-D [bind_address:]port] [-E log_file] [-e escape_char]            [-F configfile] [-I pkcs11] [-i identity_file]            [-L [bind_address:]port:host:hostport] [-l login_name] [-m mac_spec]            ...

— ngm_code

@Ramhound Eu reformulei a pergunta para ser mais direta. Por favor, retire a postagem ou faça comentários mais específicos sobre o motivo pelo qual ela foi colocada em espera.

— ngm_code

@DavidPostill Eu não concordo com este post sendo colocado em espera. A questão, o que faz com que a mensagem de erro assim e assim é, na minha opinião, perfeitamente aceitável.

— MariusMatutiae

Respostas:

Porque ssh -N -R 2222:localhost:22 <bluehost_user>@<bluehost_ip> resultar em um erro "Encaminhamento de porta remoto falhou para a porta de escuta"?

Eu recebo este aviso exato quando tento usar uma porta que já está sendo tomada no lado remoto.

A saída de netstat de bluehost indica que algo já está escutando na porta 2222 lá. Não mostra o que é isso.

Soluções:

mudança 2222 na tua ssh invocação para alguma outra porta que não está em uso em bluehost. Basta torná-lo maior que 1023 porque usuários comuns não podem se ligar a portas bem conhecidas ; caso contrário, você receberá o mesmo aviso, independentemente de a porta estar em uso ou não.
Ou identifique o processo de escuta bluehost ) com sudo lsof -i TCP:2222; terminar ou reconfigurá-lo para fazer a porta 2222 acessível.

Editar:

No seu caso, esta parte do man ssh parece importante:

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

[...] Por padrão, os soquetes de escuta do TCP no servidor serão vinculados somente à interface de loopback. Isso pode ser substituído especificando um bind_address. Um vazio bind_address, ou o endereço " * ', Indica que o soquete remoto deve escutar em todas as interfaces. Especificando um controle remoto bind_address só terá sucesso se o servidor GatewayPorts opção está ativada (consulte sshd_config(5) ).

Isso significa que você deveria ter GatewayPorts yes no sshd_config em bluehost. Ler man 5 sshd_config aprender mais. Não esqueça de recarregar o serviço depois.

— Kamil Maciorowski
fonte

Curiosamente, estou vendo uma conexão da China (note que eu estava usando este host como uma VPN da China quando estive lá há algumas semanas). Enquanto este host é um sandbox, ainda é preocupante

<bluehost_user>@<bluehost_ip>:~$ netstat | grep 2222 tcp        0      0 <bluehost_ip>:2222     htuidc.bgp.ip:2599      SYN_RECV

Port 2222 aberto ou não, como se conectar sem um nome de usuário e senha (note que isso é tcp não ssh)? Eu tenho sshd ouvindo em 2222 como configurado em /etc/ssh/sshd_config.

— ngm_code

Informação adicional de lsof:

COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME sshd    1034 root    3u  IPv4  13344      0t0  TCP *:2222 (LISTEN) sshd    1034 root    4u  IPv6  13353      0t0  TCP *:2222 (LISTEN)

— ngm_code

@ngm_code Então é o seu sshd que precisa ser reconfigurado. Ou apenas use outra porta quando você ssh -R de outro lugar.

— Kamil Maciorowski

Ok, vou dar uma olhada. Então você está dizendo que é incompatível abrir uma porta via /etc/ssh/sshd_config antes de abri-lo em tempo de execução através de uma chamada para ssh no CLI?

— ngm_code

@ngm_code Sim. Portas (ou uma porta, geralmente 22 ) configurado em sshd_config são para clientes SSH se conectarem. No seu caso você se conecta a uma dessas portas e pede sshd abrir adicional portar e encapsulá-lo na sua máquina. Se pudesse ser a mesma porta, sshd não saberia se os pacotes recebidos são destinados a ele ou ao túnel.

— Kamil Maciorowski

Certifique-se de que não haja conexão suspensa na porta 2222 no bluehost. Teste no bluehost lsof -t -i:2222 se qualquer ID de processo está usando a porta 2222. Além disso, mate esse processo (por exemplo, com kill $(lsof -t -i:2222) ).

Isso resolveu o problema para mim. Espero que esta informação seja útil para outra pessoa. :)

— jervtub
fonte