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.
Parece que você deveria estar usando o encaminhamento de porta local em vez do encaminhamento de porta remoto. Você pode consultar a seguinte postagem de blog útil de Dirk Loss:
Inclui o seguinte diagrama ilustrativo:
Para ler o diagrama, você precisa saber que ele descreve as relações entre 4 papéis diferentes envolvidos na criação e utilização de um túnel SSH:
ssh
, o cliente de linha de comando OpenSSH) usado para estabelecer o túnel;sshd
, o daemon do servidor OpenSSH) usado para manter a outra extremidade do túnel;Também é importante entender que os dois tipos diferentes de encaminhamento correspondem a dois casos de uso diferentes:
Encaminhamento local: onde o aplicativo cliente se conecta por meio do cliente ssh
Encaminhamento remoto: onde o aplicativo cliente se conecta via servidor ssh
O encaminhamento remoto é assim chamado porque o encaminhamento é executado remotamente (no servidor ssh) em vez de localmente (no cliente ssh). Também acho que "encaminhamento remoto = encaminhamento reverso" é um mnemônico útil.
Como você pode ver, para iniciar uma conexão de um
ssh
cliente noorigin
host por meio de umsshd
servidor em um proxyjumphost
para um terceirotarget
host, você teria que usar o encaminhamento de porta local. O encaminhamento de porta remoto é para o caso em que você deseja que o ponto de entrada para o túnel esteja localizado no host que executa osshd
servidor, e não no host que executa ossh
cliente.Na página de manual, a sintaxe de encaminhamento de porta local é escrita da seguinte forma:
Isso pode ser escrito de forma mais intuitiva como o seguinte:
Ou, usando suas convenções de nomenclatura:
Se modificarmos seu comando para usar o encaminhamento de porta local, terminaremos com o seguinte: