Temos um problema ao fazer conexões SSH por meio do encaminhamento de porta remota.
O cenário é uma rede corporativa, onde um servidor da rede interna (vamos chamá-la de “origem”) deve logar via SSH em um servidor da DMZ (“destino”). Como o servidor de destino na DMZ está bloqueado para conexões da rede interna (e nem pode ser visto da rede interna), temos um host de salto na DMZ pela qual passamos ("jumphost"). Fazemos isso configurando o encaminhamento de porta remota no jumphost.
Executamos este comando do servidor de origem na rede interna para o jumphost:
origin> ssh -R *:1234:target:22 myusername@jumphost
Isso é para estabelecer uma sessão SSH no jumphost, fazê-lo começar a ouvir na porta 1234 (apenas um exemplo de número de porta arbitrário) e encaminhar conexões nessa porta para a porta 22 (SSH) do servidor de destino.
Em seguida, estabelecemos uma segunda sessão SSH, ainda do servidor de origem para o jumphost, na porta 1234, que então se conecta ao servidor de destino na porta 22 - esta é a nossa sessão SSH 'real' onde podemos fazer nosso trabalho no servidor alvo:
origin> ssh jumphost -P 1234
Configuração
O host de salto foi configurado para permitir o encaminhamento de porta remota, com as seguintes configurações em sshd_config:
AllowTcpForwarding yes
GatewayPorts yes
Além disso, existem aberturas de firewall entre o servidor de origem e o host de salto, para a porta 22 (para a conexão SSH inicial para configurar o encaminhamento de porta remota) e a porta 1234 (para a conexão SSH subsequente na porta encaminhada). Há também um firewall entre o jumphost e o destino, que foi aberto na porta 22.
Resultado
Quando estabelecemos a segunda conexão (aquela pela porta encaminhada), a conexão é imediatamente fechada ('conexão fechada pelo host remoto').
A execução do tcpdump no servidor de destino não mostra nenhuma atividade, ou seja, parece que a conexão foi bloqueada.
No entanto, conseguimos estabelecer com êxito uma sessão SSH regular do jumphost para o destino. Somente ao entrar pela porta encaminhada é que a conexão é fechada, embora ambos se conectem ao destino na porta 22.
Além disso, se fizermos o encaminhamento de porta apontar para um servidor na rede interna (ou seja, uma conexão da origem na rede interna, para o jumphost na DMZ e de volta para um terceiro servidor na rede interna), o SSH sessão é estabelecida com sucesso.
Especulação e perguntas
Tudo isso me leva a acreditar que alguma configuração de segurança de rede está em jogo, o que impede a conexão por meio da porta encaminhada no servidor de salto ao servidor de destino dentro da DMZ. Infelizmente não tenho conhecimento suficiente para saber:
(1) Uma conexão SSH vinda do servidor de origem, por meio de uma porta encaminhada no servidor de salto, é 'diferente', do ponto de vista da política de segurança de rede, que poderia ser tecnicamente bloqueada e, em caso afirmativo, como? E o que precisaria ser feito para acabar com essa restrição?
(2) Quaisquer outros motivos pelos quais esta conexão não é permitida - configuração do firewall, configuração do roteador, configurações SSH na origem ou jumphost, mais alguma coisa?
(3) Poderia falhar porque o servidor de origem não conhece o servidor de destino e, portanto, o primeiro comando ssh não funciona conforme o esperado? Em outras palavras, o nome do host especificado no primeiro comando ssh ("target") é interpretado no cliente (origem) ou no servidor ao qual estamos nos conectando para criar o túnel (o jumphost)?
O que mais me deixa perplexo é que uma sessão SSH regular pode ser estabelecida do jumphost para o destino. Eu pensaria que a conexão SSH que chega pela porta encaminhada seria a mesma, mas de alguma forma não é.
Qualquer entrada muito apreciada.