sessão SSH através do jumphost via encaminhamento de porta remota

Question

Temos um problema em fazer conexões SSH por meio do encaminhamento remoto de portas.

O cenário é uma rede corporativa, em que 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 da rede interna), temos um host de salto na DMZ pelo qual passamos ("jumphost"). Fazemos isso configurando o encaminhamento remoto de portas no jumphost.

Nós 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, fazer com que ela comece a escutar na porta 1234 (apenas um número de porta arbitrário) e encaminhar conexões naquela 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 fica conectada ao servidor de destino na porta 22 - esta é a nossa sessão SSH 'real' onde podemos fazer nossa trabalhar 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, há 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 subseqüente 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 fechada ('conexão fechada pelo host remoto').

A execução do tcpdump no servidor de destino não mostra atividade, ou seja, parece que a conexão é bloqueada.

No entanto, somos capazes de estabelecer com sucesso uma sessão SSH regular do jumphost para o destino. Somente quando entrar pela porta encaminhada é que a conexão é fechada, embora ambos se conectem ao destino na porta 22.

Além disso, se fizermos o ponto de encaminhamento de porta para um servidor na rede interna (ou seja, uma conexão de origem na rede interna, para o jumphost na DMZ e de volta para um terceiro servidor na rede interna), então a sessão SSH é 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 para o servidor de destino dentro da DMZ. Infelizmente não tenho conhecimento suficiente para saber:

(1) Existe 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, que pode ser tecnicamente bloqueada e, em caso afirmativo, como ? E o que precisaria ser feito para levantar essa restrição?

(2) Quaisquer outras razões pelas quais esta conexão não é permitida - configuração do firewall, configuração do roteador, configurações do SSH na origem ou jumphost, qualquer outra 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 como previsto? Em outras palavras, o nome do host especificado no primeiro comando ssh ("target") foi interpretado no cliente (origem) ou no servidor ao qual estamos nos conectando para criar o túnel (o jumphost)?

O que mais me incomoda é que uma sessão SSH regular pode ser estabelecida do jumphost para o destino, eu acho que a conexão SSH que entra pela porta encaminhada seria a mesma, mas de alguma forma não é. / p>

Qualquer entrada muito apreciada.

    

Answer 1

Parece que você deve estar usando encaminhamento de porta local em vez de encaminhamento de porta remoto. Você pode querer consultar a seguinte postagem no blog por Dirk Loss:

• encaminhamento de porta SSH visualizado

Inclui o seguinte diagrama ilustrativo:

Paralerodiagrama,vocêprecisasaberqueeledescreveasrelaçõesentreos4diferentespapéisenvolvidosnacriaçãoeutilizaçãodeumtúnelSSH:

• umclientessh(porexemplo,ssh-oclientedalinhadecomandoOpenSSH)usadoparaestabelecerotúnel;
• umservidorssh(porexemplo,sshd-odaemondoservidorOpenSSH)usadoparamanteraoutraextremidadedotúnel;
• umservidordeaplicativos(porexemplo,outroservidorsshouumservidorhttp);
• umclientedeaplicativo(porexemplo,outroclientesshouumnavegadordaWeb)quedesejaacessaroservidordeaplicativospormeiodotúnel.

Tambéméimportanteentenderqueosdoistiposdiferentesdeencaminhamentocorrespondemadoiscasosdeusodiferentes:

• Encaminhamentolocal:ondeoclientedeaplicativoseconectapormeiodoclientessh

• RemoteForwarding:ondeoaplicativoclienteseconectapormeiodoservidorssh

Oencaminhamentoremotoéassimchamadoporqueoencaminhamentoéexecutadoremotamente(noservidorssh)enãolocalmente(noclientessh).Eutambémacho"encaminhamento remoto = encaminhamento reverso" para ser um mnemônico útil.

Como você pode ver, para iniciar uma conexão de um cliente ssh no host origin por meio de um servidor sshd em um proxy jumphost para um terceiro host target , seria necessário use o encaminhamento de porta local. O encaminhamento remoto de porta é para o caso em que você deseja que o ponto de entrada para o túnel seja localizado no host que está executando o sshd server em vez de no host que está executando o ssh client.

Na página man, 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 da seguinte forma:

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, acabaremos com o seguinte:

user@origin:~$ ssh -L *:1234:target:22 myusername@jumphost