Na chamada de encaminhamento de porta local abaixo,
[me@TunnelBeginHost]$ ssh -L TunnelBeginPort:TunnelEndHost:TunnelEndPort ViaUser@ViaHost
, devido ao fato de que a parte do túnel entre ViaHost e TunnelEndHost é insegura, propensa a sniffing de rede e tudo isso, por que ssh fornece essa opção? Segurança sendo o coração de ssh , não deveria ter exigido autenticação no TunnelEndHost também ..., digamos com uma sintaxe (hipotética) como,
[me@TunnelBeginHost]$ # Proposed syntax:
[me@TunnelBeginHost]$ ssh -L TunnelBeginPort:TunnelEndUser:TunnelEndHost:TunnelEndPort ViaUser@ViaHost
que teria garantido um túnel seguro entre ViaHost e TunnelEndHost também?
Da mesma forma, para encaminhamento de porta remota.
Entender a lógica por trás dessa capacidade de ssh ajudará a esclarecer qualquer conceito errado que eu possa ter sobre ssh -tunneling ou sobre as advertências de segurança associadas a ele.
O encaminhamento de fora do host é um recurso de parte segura e parte insegura de ssh , tornando-o geral um recurso inseguro.
A página man de ssh deve incluir uma advertência explícita sobre isso. Lamentavelmente, isso não acontece, a partir da versão openssh-clients-5.8p2-25.fc16.i686 .
Primeiro, " a parte do túnel entre o ViaHost e o TunnelEndHost é insegura " não é um fato . Você assume que o host final será conectado pela Internet pública, mas nem sempre é esse o caso - talvez eu esteja usando o encapsulamento para HTTPS, pode estar passando por IPsec, VPN criptografada ou apenas uma conexão a cabo fisicamente segura. Minha LAN de máquina virtual não é propensa a cheirar, desde que eu seja a única com root no meu próprio laptop.
Em segundo lugar, o que @Xeross disse - como você autenticaria em seu esquema proposto? Usando o protocolo? O recurso de túnel foi criado para suportar conexões TCP arbitrárias. E se o host final não suportar o SSH, o TLS ou o seu protocolo favorito? Se você decidiu exigir suporte SSH no host final, todo o recurso de túnel se tornará praticamente inútil, já que o usuário poderia apenas conectar o SSH ao host final diretamente.
Por fim, por que não? ssh não pode conhecer melhor as condições de rede do usuário do que o próprio usuário (como visto no primeiro parágrafo), e adicionar restrições arbitrárias como essa pode dificultar seu trabalho . ssh está aqui para ajudar, mas não para tomar conta, como é tradição dos programas Unix.
Como exatamente essa autenticação de ponto de extremidade funcionaria, considerando o ponto de extremidade poderia ser qualquer coisa, HTTP, HTTPS, etc. (você entendeu a ideia).
Se o tráfego precisar ser criptografado, qualquer protocolo que você esteja tentando enviar pelo túnel terá que cuidar dele.
Tags ssh security port-forwarding