História do SSH: do telnet ao OpenSSH

Onde começa a história do SSH

A história do SSH começa com palavras-passe roubadas. Antes de 1995, iniciar sessão numa máquina Unix remota significava usar telnet ou rlogin, e ambos enviavam a palavra-passe pela rede em texto legível. Qualquer pessoa que conseguisse monitorizar o tráfego podia lê-la, e no início da década de 1990 já havia pessoas a fazer isso em grande escala.

O SSH foi a resposta de uma pessoa a esse problema, escrito em 1995 e disponibilizado gratuitamente. Desde então, o protocolo foi reconstruído uma vez, e o programa que quase toda a gente usa atualmente é um fork de um fork. As datas abaixo são importantes, porque cada etapa foi uma resposta a uma falha específica.

O que o telnet e o rlogin realmente enviavam

O Telnet é definido na RFC 854, publicada em maio de 1983 por Jon Postel e Joyce Reynolds. O documento descreve uma sessão de terminal transportada por TCP e não inclui qualquer tipo de encriptação. Cada byte que escreve, incluindo a sua palavra-passe, é transmitido como bytes simples que qualquer dispositivo no caminho pode ler.

O rlogin surgiu no Berkeley Unix e foi documentado mais tarde na RFC 1282 (BSD Rlogin, B. Kantor, dezembro de 1991). Introduziu algo pior do que uma palavra-passe legível: confiança baseada no host. Era possível configurar um servidor para aceitar ligações de um host identificado pelo nome sem exigir qualquer palavra-passe. A RFC inclui uma secção intitulada "A Cautionary Tale", que afirma: "Bypassing password authentication from trusted hosts opens ALL the systems so configured when just one is compromised." Também observa que a confiança é associada aos nomes dos hosts. Por isso, um comprometimento do DNS (domain name system) ou um endereço falsificado consegue contornar essa confiança.

Ambos os desenhos eram adequados à rede em que foram criados. A Ethernet inicial era um meio partilhado: todas as máquinas de um segmento recebiam todas as tramas e deviam ignorar as tramas que não lhes eram endereçadas. Uma máquina que deixasse de as ignorar, que é o significado de modo promíscuo, via o tráfego das outras máquinas. Se acrescentarmos uma universidade que fornecia contas shell a milhares de estudantes, uma única conta comprometida podia tornar-se num coletor de palavras-passe de todo um departamento.

O comunicado de 1994 que não veio acompanhado de uma correção

Em 3 February 1994, a CERT publicou o comunicado CA-94:01, "Ongoing Network Monitoring Attacks". O comunicado informava que invasores tinham capturado informações de acesso de dezenas de milhares de sistemas na internet. A ferramenta usada colocava a interface de rede em modo promíscuo e registava o início de cada nova sessão telnet, rlogin e FTP. Essa parte contém o nome de utilizador e a palavra-passe.

A CERT recomendou que os sites alterassem a palavra-passe de todas as contas acessíveis pela rede. Quando essa recomendação é analisada em conjunto com os protocolos, o problema fica claro: a nova palavra-passe atravessa a mesma rede em texto simples na primeira utilização. Não havia correção possível dentro do telnet ou do rlogin, porque nenhum dos dois protocolos tinha um mecanismo para a transportar com segurança.

Por que um ataque de sniffing em Helsínquia produziu o SSH

Em 1995, a rede da Universidade de Tecnologia de Helsínquia foi alvo de um ataque de captura de palavras-passe do tipo descrito pela CERT. Tatu Ylönen, um investigador da universidade, criou um substituto e lançou-o como freeware em julho de 1995. Chamou-lhe Secure Shell.

Duas decisões de conceção foram determinantes. A sessão era encriptada, por isso um intruso que monitorizasse o segmento não obtinha informações úteis. E o servidor provava a sua identidade com uma chave, permitindo ao cliente confirmar se tinha chegado à máquina correta. Esta era a lacuna deixada pela confiança no nome do anfitrião do rlogin.

Também se difundiu porque os comandos correspondiam aos que os utilizadores já escreviam. ssh substituía rsh e rlogin, e scp substituía rcp. A mudança exigia adaptar um hábito, não alterar um fluxo de trabalho. No final de 1995, a base de utilizadores tinha atingido aproximadamente 20,000 utilizadores em cinquenta países. Nesse dezembro, Ylönen fundou a SSH Communications Security para desenvolver e vender o software.

De uma versão gratuita a um produto comercial

À medida que o SSH se tornou um negócio, a licença do código-fonte mudou. As versões posteriores passaram a incluir termos que limitavam o que outras pessoas podiam fazer com o código, e a última versão que qualquer pessoa podia reutilizar livremente foi a ssh 1.2.12. Não havia nada de impróprio nisso. Isso significava apenas que a versão do SSH sobre a qual o resto do mundo podia construir deixou de avançar, enquanto o desenvolvimento continuava num local que esse mundo não podia acompanhar. As licenças determinam que código sobrevive, um padrão que vale a pena conhecer em como o licenciamento de código aberto moldou a infraestrutura moderna.

Por que o OpenBSD criou um fork do OpenSSH em 1999

No início de 1999, Björn Grönvall voltou à última versão livre e começou a corrigir os erros existentes. A versão dele chamava-se OSSH e falava apenas o protocolo SSH 1.3.

O projeto OpenBSD adotou o OSSH e reconstruiu-o. Segundo o próprio projeto, Theo de Raadt, Niels Provos, Markus Friedl, Bob Beck, Aaron Campbell e Dug Song fizeram o trabalho de limpar, auditar e ampliar o código. O resultado foi o OpenSSH 1.2.2, incluído no OpenBSD 2.6 em 1 de dezembro de 1999.

Por que um fork criado por um pequeno projeto de sistema operativo acabou em quase todas as máquinas? Por causa do que o OpenBSD precisava dele. O OpenBSD inclui um sistema base auditado, concebido para ser seguro na configuração predefinida. Por isso, o login remoto cifrado tinha de fazer parte desse sistema base, com uma licença sem restrições. Código auditado sob uma licença sem restrições era precisamente o que todos os outros fornecedores de sistemas operativos também queriam. Damien Miller, Philip Hands e outros começaram quase imediatamente uma branch portável. É daí que vem o p numa versão como 10.5p1. O OpenBSD desenvolve a versão limpa, e a branch portável acrescenta a integração necessária para todo o resto. A forma como o Unix se dividiu nos sistemas que usamos atualmente explica por que essa integração é necessária.

O suporte à segunda versão do protocolo veio depois. O OpenSSH 2.0 foi incluído no OpenBSD 2.7 em 15 de junho de 2000.

Por que o SSH-2 é um protocolo novo, e não apenas um aumento de versão

O SSH-1 protegia a integridade do fluxo cifrado com CRC-32, uma soma de verificação concebida para detetar erros de transmissão, e não para resistir a um atacante. Em 1998, Ariel Futoransky e Emiliano Kargieman, da CORE SDI, demonstraram as consequências. Com os modos de cifra CBC ou CFB e uma verificação CRC-32, um atacante que conheça apenas 16 bytes do texto simples pode inserir texto cifrado escolhido que o recetor aceita como legítimo. Isso permite executar comandos no servidor.

A falha fazia parte do protocolo e, por isso, não podia ser corrigida sem quebrar a compatibilidade. Em vez disso, as implementações passaram a incluir um detetor: código num ficheiro chamado deattack.c que tentava reconhecer o ataque enquanto este ocorria. Em fevereiro de 2001, descobriram que o próprio detetor continha um overflow de inteiros, CVE-2001-0144. Isso permitia a execução remota de código contra servidores e clientes que tinham a correção instalada. Um desenho que não pode ser reparado acumula patches, e os patches trazem os seus próprios bugs.

O SSH-2 foi desenvolvido num grupo de trabalho do IETF chamado secsh e publicado como RFCs em janeiro de 2006: a arquitetura no RFC 4251, a camada de transporte no RFC 4253, a autenticação de utilizadores no RFC 4252 e a camada de ligação no RFC 4254. A divisão em camadas é a parte importante, porque permite substituir cada camada de forma independente. Grande parte do restante desta história consiste nessa substituição.

Destacam-se duas alterações. A integridade passou de CRC-32 para um HMAC (código de autenticação de mensagens baseado em hash) protegido por uma chave derivada de um segredo partilhado. Assim, um atacante que não consiga calcular o MAC não consegue forjar um pacote. O acordo de chaves passou a usar Diffie-Hellman. No SSH-1, o cliente escolhia a chave da sessão e enviava-a cifrada com as chaves RSA do servidor. Por isso, qualquer pessoa que obtivesse mais tarde essas chaves privadas poderia decifrar uma sessão gravada. O Diffie-Hellman deriva um segredo novo para cada sessão, que nunca é transmitido. Assim, gravar o tráfego agora e roubar a chave do host mais tarde não permite obter informação. Esta propriedade chama-se sigilo permanente.

O SSH-2 não partilha compatibilidade de rede com o SSH-1. É por isso que o número mudou, em vez de apenas mudar a parte decimal.

Por que o SSH-1 foi removido em vez de corrigido

A remoção ocorreu em três releases do OpenSSH. A versão 7.0, em 11 August 2015, desativou o protocolo 1 por predefinição no momento da compilação. A versão 7.4, em 19 December 2016, removeu o suporte do servidor. A versão 7.6, em 3 October 2017, também eliminou o lado do cliente, juntamente com as respetivas opções de configuração e documentação.

Mantê-lo como opção para equipamentos antigos teria sido uma escolha mais compatível, mas o detetor de CRC-32 explica por que essa escolha foi recusada. O overflow só era alcançável porque o código do protocolo 1 estava incluído na compilação e encontrava-se num caminho que a maioria dos administradores considerava inativo nos seus sistemas. O código incluído numa release pode ser alcançado. O código eliminado não pode.

Por que a primeira ligação SSH avisa sobre a chave do host

A encriptação indica que o tráfego é privado. Não indica quem está na outra extremidade. Se um atacante se colocar no caminho e responder em vez do seu servidor, terá uma sessão perfeitamente encriptada com o atacante. Isto é um ataque de máquina no meio. O SSH responde a este risco com uma chave de host: o servidor prova que possui a parte privada de um par de chaves, e o cliente compara essa chave com a que registou anteriormente. Se quiser conhecer o funcionamento da própria ligação, consulte o que acontece quando abre uma ligação SSH.

Na primeira ligação não existe uma ligação anterior. Por isso, o cliente não tem nada para comparar e tem de lhe perguntar:

The authenticity of host 'vps.example.com (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:BQ0Qs2jVXhH2lPZ2rM0aQ0mQ8f9pQ0m3nH0oQ1bYqkE.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Responder yes armazena essa chave em ~/.ssh/known_hosts. Em todas as ligações seguintes, o cliente compara a chave com o valor armazenado. Se houver uma diferença, é apresentada a mensagem mais grave que o programa tem:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

A interpretação correta desse primeiro aviso é que o protocolo está a admitir o seu único momento de menor segurança. A confiança na primeira utilização significa que a primeira ligação só é tão segura quanto a rede usada para a estabelecer. É possível eliminar essa lacuna. Leia a impressão digital na consola do seu fornecedor ou no log de compilação do servidor antes de estabelecer a ligação. Publique-a no DNS como um registo SSHFP (RFC 4255), mas isso só é útil se utilizar DNSSEC. Outra opção é assinar as chaves de host com a sua própria autoridade de certificação (CA), para que os clientes confiem na CA e não em cada chave individual. Na prática, a maioria das pessoas aceita o aviso sem verificar a chave. É importante reconhecer isso.

Como as chaves públicas deixaram as palavras-passe para trás

A autenticação por chave pública existe desde as primeiras versões do SSH, mas foram necessários anos para se tornar o procedimento normal. O mecanismo é assimétrico: o cliente prova que possui uma chave privada ao assinar um desafio, e a chave privada nunca sai do cliente. Uma palavra-passe faz o contrário. Embora o SSH a transporte dentro do canal cifrado, o servidor recebe o segredo real. Por isso, um servidor comprometido ou malicioso fica com algo que pode reutilizar contra si noutros serviços.

A segunda razão é matemática. Qualquer servidor com a porta 22 aberta num endereço público recebe tentativas de início de sessão automatizadas continuamente, e uma palavra-passe é uma sequência que pode ser adivinhada. Uma chave não pode ser adivinhada de forma viável. Definir PasswordAuthentication no elimina toda essa categoria de ataque, motivo pelo qual esta opção aparece em todas as listas de verificação de hardening. A geração e a rotação de chaves são abordadas em Noções básicas de gestão de chaves SSH, e as definições do lado do servidor em hardening do SSH num VPS.

Por que a lista de algoritmos do SSH continua a mudar

Um protocolo em camadas permite retirar algoritmos sem criar um protocolo novo. O OpenSSH tem usado essa liberdade de forma consistente, e as datas de lançamento mostram o ritmo.

O Ed25519 chegou ao OpenSSH 6.5 em 30 January 2014, juntamente com a cifra chacha20-poly1305 e um formato de chave privada protegido por bcrypt. As assinaturas Ed25519 derivam deterministicamente o nonce de cada assinatura. Por isso, um gerador de números aleatórios fraco no momento da assinatura não consegue expor a chave privada. Foi exatamente assim que chaves privadas DSA e ECDSA foram recuperadas em incidentes reais.

O DSA seguiu o caminho oposto. O OpenSSH 7.0 desativou ssh-dss chaves de host e de utilizador em tempo de execução em 2015, porque o algoritmo está limitado a uma chave privada de 160 bits e ao SHA-1. A versão 9.8, em 1 July 2024, desativou o DSA em tempo de compilação. A versão 10.0, em 9 April 2025, removeu-o. Nas palavras do projeto, isso "completa o processo de descontinuação iniciado em 2015". Dez anos entre a desativação e a remoção.

O RSA não desapareceu, mas o seu formato de assinatura antigo desapareceu. O OpenSSH 8.8, em 26 September 2021, deixou de aceitar por predefinição assinaturas RSA feitas com SHA-1. As notas da versão indicam claramente o motivo: o SHA-1 está quebrado do ponto de vista criptográfico, e era possível obter colisões de prefixo escolhido por menos de USD 50,000. Se alguma vez encontrou sign_and_send_pubkey: no mutual signature supported ao ligar-se a um servidor antigo, esta é a alteração em causa. A sua chave está correta. O algoritmo de assinatura solicitado pelo outro lado é que não está.

O mesmo processo está agora a ocorrer com a troca de chaves, desta vez antes de a ameaça existir. O tráfego capturado hoje pode ser armazenado e desencriptado anos mais tarde por quem obtiver primeiro um computador quântico capaz. Por isso, o acordo de chaves teve de mudar antes de existir uma máquina desse tipo. O OpenSSH 9.0, em 8 April 2022, tornou uma troca de chaves híbrida a predefinição: sntrup761x25519-sha512@openssh.com combina um algoritmo pós-quântico com a troca X25519. Assim, se o novo algoritmo for insuficiente, o resultado não fica mais fraco do que a parte clássica. O OpenSSH 9.9, em 19 September 2024, adicionou mlkem768x25519-sha256, baseado no ML-KEM (mecanismo de encapsulamento de chaves baseado em reticulados), normalizado pelo NIST em 2024. O OpenSSH 10.0 tornou-o a predefinição para o acordo de chaves, e a página pós-quântica do projeto explica o motivo. O OpenSSH 10.1, em 6 October 2025, começou a emitir um aviso quando o outro lado não consegue utilizá-lo:

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded.

Esse aviso está ativado por predefinição e é controlado pela opção WarnWeakCrypto em ssh_config. O que isso significa na prática e o que fazer com um servidor que o desencadeia é explicado em as predefinições pós-quânticas da troca de chaves SSH.

O que este histórico significa para o servidor à sua frente

O comando que escreve mudou muito pouco desde 1995. Quase tudo o que está por baixo foi substituído: a verificação de integridade, a troca de chaves, os algoritmos de assinatura e a própria base de código. Isso só foi possível porque cada substituição terminou com uma remoção deliberada, e cada remoção causou uma falha para alguém.

Por isso, a segurança do SSH depende principalmente da sua versão. Os valores predefinidos incorporam as decisões sobre os algoritmos oferecidos, recusados e sobre os avisos apresentados. Um servidor antigo continua a oferecer tudo o que a sua versão ainda permitia e continua a fazer a negociação com versões inferiores para aceitar clientes antigos. Em agosto de 2026, a versão atual é o OpenSSH 10.5, publicado em 11 de agosto de 2026. A distância entre essa versão e a versão instalada numa máquina que ninguém atualiza há três anos indica a dimensão do problema. Verificar a versão faz parte de os primeiros dez minutos num novo VPS.

FAQ

Quem criou o SSH e porquê?

Tatu Ylönen, investigador da Helsinki University of Technology, criou o SSH em 1995, depois de um ataque de captura de palavras-passe na rede da universidade. As ferramentas de início de sessão remoto usadas na altura, telnet e rlogin, enviavam as palavras-passe pela rede como texto legível. Assim, qualquer pessoa que monitorizasse um segmento partilhado recolhia as credenciais à medida que passavam. Ele lançou o programa como freeware em julho de 1995. No fim desse ano, o programa tinha aproximadamente 20,000 utilizadores em cinquenta países. Em dezembro de 1995, fundou a SSH Communications Security.

Qual é a diferença entre SSH-1 e SSH-2?

São protocolos diferentes e não são compatíveis ao nível do protocolo de rede. O SSH-1 era um protocolo monolítico que usava CRC-32 para garantir a integridade. O cliente enviava uma chave de sessão encriptada com as chaves RSA do servidor. O SSH-2 separa o trabalho numa camada de transporte, numa camada de autenticação e numa camada de ligação (RFCs 4251 a 4254, janeiro de 2006). Usa um HMAC para garantir a integridade e deriva as chaves de sessão com Diffie-Hellman. Assim, o tráfego capturado continua privado mesmo que a chave do host seja roubada posteriormente. O SSH-1 foi removido do OpenSSH por etapas. O processo terminou na versão 7.6, em outubro de 2017.

Por que razão o OpenSSH substituiu a implementação original do SSH?

O desenvolvimento da implementação original passou para um produto comercial com uma licença restritiva. A última release que podia ser reutilizada livremente foi a ssh 1.2.12. No início de 1999, Björn Grönvall recuperou essa release como OSSH. A equipa do OpenBSD criou um fork do OSSH chamado OpenSSH, que foi incluído no OpenBSD 2.6 em 1 de dezembro de 1999. O OpenBSD precisava de código auditado, com uma licença sem restrições, para o seu sistema base. Essas duas características permitiram que todos os outros sistemas operativos distribuíssem a mesma implementação através do ramo portátil.

Por que razão o SSH pergunta pela chave do host na primeira ligação?

Porque o cliente nunca viu esse servidor antes e não tem nenhuma chave com a qual possa comparar a chave recebida. A encriptação, por si só, não distingue um servidor legítimo de uma máquina colocada no meio do caminho. Por isso, o SSH identifica os servidores pela chave e regista o que recebeu em ~/.ssh/known_hosts. A primeira ligação é o único momento em que não existe um valor guardado para verificar. É por isso que o cliente lhe pergunta diretamente. Compare a impressão digital com uma obtida na consola do fornecedor ou no próprio servidor. Trate qualquer mensagem posterior REMOTE HOST IDENTIFICATION HAS CHANGED como um evento real até conseguir explicá-la.

Por que razão as chaves SSH antigas deixam de funcionar depois de uma atualização?

Porque o OpenSSH descontinua algoritmos segundo um calendário publicado. As chaves DSA (ssh-dss) foram desativadas por predefinição no OpenSSH 7.0, em 2015, e removidas definitivamente no OpenSSH 10.0, em 9 de abril de 2025. As chaves RSA continuam a funcionar, mas as assinaturas feitas com SHA-1 foram desativadas por predefinição no OpenSSH 8.8, em setembro de 2021. Ao ligar-se a um servidor antigo, isto aparece como sign_and_send_pubkey: no mutual signature supported. Uma chave Ed25519, disponível desde o OpenSSH 6.5, em janeiro de 2014, evita ambos os problemas.