SSH e TELNET permitem que você se conecte a computadores remotos em rede e os use como se estivesse sentado na frente deles. Então, qual é a diferença entre esses dois protocolos veneráveis, e há realmente sempre uma vantagem em usar SSH sobre TELNET?
Índice
TELNET e SSH: a história da origem
Necessidade é a mãe da invenção. Os administradores de sistema precisavam de uma forma de acessar e gerenciar computadores localizados fisicamente em outro lugar. Se fosse impraticável ou inconveniente para o administrador se posicionar na frente do computador, ele precisava de uma maneira de acessar o computador remoto que lhe permitisse emitir comandos como se os estivesse digitando naquele computador.
TELNET , abreviação de tel etype over net work protocol, foi desenvolvido em 1969 como resposta a esse problema. Desde que o computador remoto fosse acessível pela rede, ele permitia ao administrador, ou qualquer outra pessoa autorizada, conectar-se a ele e usá-lo como se estivesse pressionando fisicamente as teclas do teclado remoto.
O SSH foi criado muito mais tarde – em 1995 – como uma resposta direta ao Telnet e outras soluções semelhantes. A necessidade desta vez era segurança. TELNET, rlogin , FTP e outros protocolos daquela época foram projetados sem qualquer consideração ou necessidade percebida de segurança.
SSH significa shell seguro , então você pode ver que a segurança foi um princípio orientador desde o seu início . Hoje em dia, o SSH substituiu quase totalmente o TELNET.
TELNET é um pesadelo de segurança em texto simples
O grande problema do TELNET é que ele usa texto simples. Ele não criptografa nenhum tráfego, incluindo nomes de usuário e senhas. Qualquer coisa que ele transmita ao longo da rede pode ser capturada por detecção de pacotes e lida com a maior facilidade. Este é um risco de segurança mesmo em uma rede local, a menos que você seja o único usuário. Qualquer usuário pode interceptar o tráfego TELNET e obter credenciais de login às quais não tem direito.
Se o computador remoto estiver fora do local, exigindo uma conexão pela Internet para alcançá-lo, o problema será ampliado imensamente. O TELNET foi um produto do seu tempo e, para ser justo com eles, os autores quase certamente não esperavam que as pessoas o utilizassem mais de cinquenta anos depois, no cenário de TI muito diferente de hoje.
Embora o TELNET mereça o seu lugar na lista de programas importantes que coletivamente ajudaram a chegar onde estamos hoje, não é algo que ainda devamos usar no mundo de hoje.
TELNET x SSH: Qual é a diferença?
À primeira vista, TELNET e SSH são duas respostas para o mesmo problema. Ambos permitem acessar uma janela de terminal em um computador remoto e emitir comandos para ela. Mas como o SSH foi desenvolvido muito mais tarde que o TELNET, o problema foi mais bem compreendido e a resposta foi melhor projetada.
O TELNET foi projetado tendo em mente as redes privadas, mas o SSH foi projetado para lidar com redes públicas e com a necessidade de manter a privacidade e a segurança ao transferir dados e fazer conexões remotas.
O TELNET usa a porta 23 e esse número de porta não pode ser alterado. Por padrão, o SSH usa a porta 22, mas isso pode ser configurado e alterado. Configurar o SSH para usar um número de porta não óbvio torna mais difícil para os invasores identificarem a porta SSH. Se a porta SSH puder ser identificada, será uma questão trivial montar um ataque de força bruta onde milhares de senhas coletadas de violações de dados são testadas por software automatizado.
Melhor ainda, o SSH pode dispensar completamente as senhas. Ele pode usar criptografia de chave pública para autenticar computadores remotos. As senhas nunca são transmitidas, pois não há necessidade de enviá-las ao computador remoto. Sua criptografia de dados e autenticação de chave SSH significam que o SSH é capaz de fornecer conexões e comunicações seguras em redes inseguras como a Internet.
Na verdade, o SSH pode ser usado para autenticação em diferentes serviços, não apenas em computadores remotos que executam um servidor SSH. Por exemplo, você pode acessar os repositórios Git hospedados no GitHub , GitLab e BitBucket usando SSH em vez de senhas.
Outra vantagem de usar SSH sobre TELNET é que o SSH pode fazer tunelamento SSH reverso . Isso exige que o servidor estabeleça uma conexão com o computador cliente. Até que o usuário local queira estabelecer uma conexão com o servidor, a conexão será ignorada.
Quando o cliente deseja se conectar ao servidor, o usuário estabelece uma conexão SSH com seu próprio computador. O SSH envia a conexão pela conexão já estabelecida para o servidor. Isto fornece um túnel privado dentro da conexão já criptografada do servidor para o cliente.
A única vantagem do TELNET é que ele utiliza menos largura de banda. Mas não estamos em 1969, onde a largura de banda era escassa, e o SSH também não é exatamente um consumidor de largura de banda.
SSH também teve seus problemas
Embora o SSH supere o TELNET quando se trata de segurança, temos que lembrar que ainda é um software, e o software pode conter bugs. Esses bugs podem levar a vulnerabilidades que podem ser exploradas por cibercriminosos. Além disso, os padrões e algoritmos de criptografia mudam com o tempo e são substituídos. Como todos os softwares baseados em criptografia, à medida que as versões mais antigas do SSH envelhecem, elas podem se tornar menos seguras. É por isso que é importante certificar-se de que você está usando a versão mais recente do SSH.
A versão do SSH usada na maioria dos computadores Linux é OpenSSH, uma implementação de SSH que se baseia no kit de ferramentas e bibliotecas OpenSSL. Em 2012, a biblioteca OpenSSL introduziu acidentalmente um bug que permitia a um invasor solicitar uma resposta do servidor SSL e especificar quantos dados conter na resposta.
Eles poderiam solicitar uma resposta de (digamos) 64 KB quando a resposta real não precisaria de mais de 64 bytes. A primeira sequência de bytes nesses dados seria a resposta genuína e esperada, seguida por tudo o que estivesse na memória usada recentemente pelo OpenSSL. O que estava contido nesses dados era sorte, mas poderia conter informações confidenciais, como cookies de sessão e senhas, ou outras informações que permitissem a um invasor adquirir chaves privadas, por exemplo.
Depois de descoberta, em 2014, a vulnerabilidade ficou conhecida como Heartbleed . Foi rapidamente corrigido no software. No entanto, a vulnerabilidade não desaparece nesse ponto. A vulnerabilidade só é completamente anulada quando todos os computadores que executam o software vulnerável têm a versão corrigida instalada. Em outras palavras, quando os computadores tiverem sido corrigidos. Como muitos administradores demoraram a reagir, a aceitação do software corrigido foi lenta.
Também preocupantes são os dois anos entre 2012, quando o bug foi introduzido, e 2014, quando foi descoberto e resolvido. Durante esses dois anos, todos os servidores SSH que executavam a versão vulnerável do OpenSSL estiveram em risco.
Para ser justo, isso aconteceu há praticamente uma década e, desde então, houve muitos lançamentos, melhorias, correções de bugs e revisões de código.
Você deve usar SSH ou TELNET?
É difícil pensar por que hoje você precisaria usar TELNET versus SSH. Isso não é o mesmo que dizer se existe algum cenário em que seja seguro usar o TELNET. Em uma rede independente que não está conectada ao mundo externo, e você tem certeza de que ninguém irá detectar seu tráfego de pacotes, você pode usar o TELNET. Mas não há razão para isso. A compensação de segurança não pode ser justificada.
O SSH é mais seguro e flexível – essa é a vantagem de usar SSH sobre TELNET. A implementação do OpenSSH é gratuita para todos os usos, inclusive comercial, e está disponível para todos os sistemas operacionais populares.
