Temos um problema ao fazer conexões SSH por meio de encaminhamento remoto de porta.
O cenário é uma rede corporativa, onde um servidor na rede interna (vamos chamá-lo de “origem”) deve efetuar login via SSH em um servidor na DMZ (“destino”). Como o servidor de destino na DMZ está bloqueado para conexões da rede interna (e nem pode ser visto na rede interna), temos um host de salto na DMZ pelo qual passamos ("jumphost"). Fazemos isso configurando o encaminhamento remoto de porta no jumphost.
Executamos este comando do servidor de origem na rede interna para o jumphost:
origin> ssh -R *:1234:target:22 myusername@jumphost
Isso serve para estabelecer uma sessão SSH no jumphost, fazê-lo começar a escutar na porta 1234 (apenas um exemplo de número de porta arbitrário) e encaminhar conexões nessa porta para a porta 22 do servidor de destino (SSH).
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 de destino:
origin> ssh jumphost -P 1234
Configuração
O host de salto foi configurado para permitir o encaminhamento remoto de porta, 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 alvo, que foi aberto na porta 22.
Resultado
Quando estabelecemos a segunda conexão (aquela através da porta encaminhada), a conexão é imediatamente encerrada ('conexão fechada por 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, somos capazes de estabelecer com êxito uma sessão SSH regular do jumphost para o destino. Somente ao entrar pela porta encaminhada a conexão é fechada, embora ambos se conectem ao destino na porta 22.
Além do mais, 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), então o SSH sessão foi 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 através 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 proveniente do servidor de origem, através de uma porta encaminhada no servidor de salto, é 'diferente', do ponto de vista da política de segurança de rede, de que poderia ser tecnicamente bloqueada e, em caso afirmativo, como? E o que precisaria ser feito para suspender essa restrição?
(2) Algum outro motivo pelo qual esta conexão não é permitida - configuração de firewall, configuração de roteador, configurações de 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 surpreende é 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 contribuição é muito apreciada.
Responder1
Parece que você deveria usar o encaminhamento de porta local em vez do encaminhamento de porta remoto. Você pode consultar a seguinte postagem útil de Dirk Loss no blog:
Inclui o seguinte diagrama ilustrativo:
Para ler o diagrama você precisa saber que ele descreve as relações entre 4 funções diferentes envolvidas na criação e utilização de um túnel SSH:
- um cliente ssh (ou seja
ssh, o cliente de linha de comando OpenSSH) usado para estabelecer o túnel; - um servidor ssh (ou seja
sshd, o daemon do servidor OpenSSH) usado para manter a outra extremidade do túnel; - um servidor de aplicação (por exemplo, outro servidor ssh ou um servidor http);
- um cliente de aplicação (por exemplo, outro cliente ssh ou um navegador web) que deseja acessar o servidor de aplicação através do túnel.
Também é importante compreender que os dois tipos diferentes de encaminhamento correspondem a dois casos de uso diferentes:
Encaminhamento local: onde o cliente do aplicativo se conecta através do cliente ssh
Encaminhamento Remoto: onde o aplicativo cliente se conecta através do servidor ssh
O encaminhamento remoto é assim chamado porque o encaminhamento é executado remotamente (no servidor ssh) em vez de localmente (no cliente ssh). Também considero "encaminhamento remoto = encaminhamento reverso" um mnemônico útil.
Como você pode ver, para iniciar uma conexão de um sshcliente no originhost através de um sshdservidor em um proxy jumphostpara um terceiro targethost, você teria que usar o encaminhamento de porta local. O encaminhamento remoto de porta é para o caso em que você deseja que o ponto de entrada do túnel esteja localizado no host que executa o sshdservidor, e não no host que executa o sshcliente.
Na página do manual, a sintaxe de encaminhamento de porta local é escrita da seguinte forma:
ssh -L [bind_address:]port:host:hostport user@remote
Isso pode ser escrito de forma mais intuitiva como o seguinte:
ssh -L [local_bind_address:]local_port:remote_host:remote_host_port user@proxy_host
Ou, usando suas convenções de nomenclatura:
ssh -L [origin_bind_address:]origin_port:target_host:target_host_port user@jump_host
Se modificarmos seu comando para usar o encaminhamento de porta local, teremos o seguinte:
user@origin:~$ ssh -L *:1234:target:22 myusername@jumphost