Como o SSH é diferente do Telnet?

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 realmente sempre há uma vantagem em usar o SSH sobre o TELNET?

TELNET e SSH: a história da origem

Necessidade é a mãe da invenção. Os administradores de sistema precisavam de uma maneira de acessar e gerenciar computadores fisicamente localizados 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 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 a 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 depois - em 1995 - como uma resposta direta ao Telnet e outras soluções semelhantes. A necessidade desta vez era a segurança. TELNET, rlogin, FTP e outros protocolos daquela época foram projetados sem qualquer consideração ou necessidade percebida de segurança.

SSH significa s ecure shell , então você pode ver que a segurança foi um princípio orientador desde o início. Hoje em dia, o SSH substituiu quase inteiramente o TELNET.

TELNET é um pesadelo de segurança de texto simples

O grande problema do TELNET é que ele usa texto sem formatação. Ele não criptografa nenhum tráfego, incluindo nomes de usuário e senhas. Tudo o que ele transmite pela rede pode ser capturado por sniffing de pacotes e lido com a maior facilidade. Isso é 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 aumenta imensamente. O TELNET foi um produto de seu tempo e, para ser justo com eles, os autores quase certamente não esperavam que as pessoas o usassem bem mais de cinquenta anos depois, no cenário de TI muito diferente de hoje.

Embora o TELNET mereça seu lugar na lista de programas importantes que coletivamente nos ajudaram a chegar onde estamos hoje, não é algo que ainda devêssemos usar no mundo de hoje.

Como o SSH é diferente do TELNET?

À primeira vista, TELNET e SSH são duas respostas para o mesmo problema. Ambos permitem que você acesse uma janela de terminal em um computador remoto e emita comandos para ela. Mas como o SSH foi desenvolvido muito depois do TELNET, o problema foi mais bem compreendido e a resposta foi melhor projetada.

O TELNET foi projetado com redes privadas em mente, mas o SSH foi projetado para lidar com redes públicas e 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, é uma questão trivial montar um ataque de força bruta em que 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 em computadores remotos. As senhas nunca são transmitidas, porque não há necessidade de enviá-las para o 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 executando um servidor SSH. Por exemplo, você pode acessar os repositórios Git hospedados GitHub, GitLab e BitBucket usando SSH em vez de senhas.

RELACIONADO Você deve usar HTTPS ou SSH para Git?

Outra vantagem de usar o SSH sobre o TELNET é que o SSH pode fazer o tunelamento SSH reverso. Isso requer que o servidor estabeleça uma conexão com o computador cliente. Até que o usuário local queira fazer uma conexão com o servidor, a conexão é 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. Isso fornece um túnel privado dentro da conexão já criptografada do servidor para o cliente.

A única vantagem do TELNET é que ele usa 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 devorador de largura de banda.

O 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 ter 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 garantir que você esteja usando a versão mais recente do SSH.

A versão do SSH usada na maioria dos computadores Linux é o OpenSSH, uma implementação do SSH que se baseia no kit de ferramentas e bibliotecas do OpenSSL. Em 2012, a biblioteca OpenSSL introduziu acidentalmente um bug que permitia a um invasor solicitar uma resposta do servidor SSL e especificar a quantidade de dados a 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 qualquer coisa que estivesse na memória recentemente usada pelo OpenSSL. O que estava contido naqueles 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.

Uma vez 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 corriam 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.

RELACIONADO: As melhores maneiras de proteger seu servidor SSH

Você deve usar SSH ou TELNET?

É difícil pensar em um motivo pelo qual você precisaria usar o TELNET hoje. Isso não é o mesmo que dizer se existe algum cenário em que seja seguro usar o TELNET. Em uma rede autocontida que não está conectada ao mundo externo, e você tem certeza de que ninguém vai farejar seu tráfego, 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 mais flexível — essa é a vantagem de usar o SSH sobre o TELNET. A implementação do OpenSSH é gratuita para todos os usos, inclusive comercial, e está disponível para todos os sistemas operacionais populares.

RELACIONADO: Como se conectar a um servidor SSH do Windows, macOS ou Linux