GitHub vai endurecer as regras do SSH: como saber se sua chave ou cliente precisa mudar

Segurança · "Loop"

O GitHub anunciou uma rodada de mudanças no SSH que mistura três assuntos fáceis de confundir: chaves RSA, assinaturas RSA com SHA-1 e algoritmos usados para estabelecer a conexão. Para completar, a recomendação mais comum na internet costuma ser “gere uma chave nova”, mesmo quando a chave existente continua perfeitamente capaz de usar algoritmos seguros.

A atualização remove opções antigas, estabelece um tamanho mínimo para novas chaves RSA e adiciona uma troca de chaves híbrida pós-quântica. Quem usa remotes HTTPS não será afetado. Quem usa SSH deve conferir principalmente a versão do cliente e o algoritmo efetivamente negociado, não apenas o nome do arquivo em ~/.ssh.

O que vai mudar

  • Novas chaves RSA enviadas depois de 14 de outubro de 2026 precisarão ter pelo menos 3072 bits.
  • A assinatura ssh-rsa, que usa RSA com SHA-1, será retirada.
  • O mecanismo de troca de chaves diffie-hellman-group-exchange-sha256 também será removido.
  • O GitHub adicionará mlkem768x25519-sha256, uma troca de chaves híbrida pós-quântica, nas regiões anunciadas.

As duas janelas de brownout divulgadas estão marcadas para 4 de novembro e 9 de dezembro. Durante elas, clientes dependentes dos algoritmos retirados poderão falhar temporariamente, o que funciona como um aviso antes da remoção definitiva. Há uma inconsistência no ano da data final publicada no changelog oficial; por isso, o caminho seguro é validar o ambiente antes do primeiro brownout, sem depender dessa última data.

Primeiro: seu remote usa SSH?

Comece pelo repositório, sem mexer em chave alguma:

git remote -v

Uma URL como [email protected]:org/projeto.git usa SSH. Uma URL iniciada por https://github.com/ não passa por esse fluxo e não é afetada pelas mudanças. O anúncio também cita o protocolo Git sem autenticação em instalações do GitHub Enterprise Server, mas esse não é o cenário normal de um clone autenticado no github.com.

Ter uma chave RSA não significa usar SHA-1

A parte mais valiosa do anúncio é a distinção entre o tipo da chave e o tipo da assinatura. Uma chave pública pode começar com ssh-rsa e ainda assim assinar a conexão usando rsa-sha2-256 ou rsa-sha2-512. O nome ssh-rsa também foi usado para identificar a assinatura antiga baseada em SHA-1, daí a confusão.

Chaves RSA existentes são capazes de produzir assinaturas SHA-2. Se o cliente SSH é atual, ele normalmente negocia essa opção automaticamente. Portanto, a retirada de SHA-1 não obriga todo mundo que possui uma chave RSA a gerar outra. O problema aparece quando um cliente ou uma biblioteca antiga só sabe usar a assinatura legada.

Confira a versão do cliente

O comando abaixo mostra a versão do OpenSSH disponível no terminal:

ssh -V

Segundo o GitHub, o OpenSSH oferece suporte adequado a RSA com SHA-2 a partir da versão 7.2p1. Outros mínimos divulgados incluem PuTTY 0.82, libssh2 1.11.0, Go SSH 0.16.0, TeamCity 2021.2.3 e a versão 0.1.66 do fork indicado de JSch. O cuidado maior está em ferramentas embutidas, appliances, imagens antigas de CI e integrações Java que carregam sua própria biblioteca SSH.

Depois, teste a autenticação diretamente:

ssh -T [email protected]

A resposta esperada confirma o usuário autenticado e informa que o GitHub não oferece acesso a shell. O comando termina com código 1 mesmo quando a autenticação funciona, um detalhe importante para não transformar esse teste em um health check que acusa falha por engano.

E as novas chaves RSA?

A exigência de 3072 bits vale para chaves RSA novas enviadas depois de 14 de outubro. Ela não declara inválidas todas as chaves menores que já estavam cadastradas. Ainda assim, uma chave antiga, sem passphrase ou espalhada por máquinas que ninguém mais controla pode merecer rotação por motivos independentes dessa mudança.

Para uma chave nova, o GitHub recomenda Ed25519 sempre que o ambiente oferecer suporte. RSA continua disponível quando existe alguma necessidade de compatibilidade, desde que a nova chave tenha ao menos 3072 bits. A escolha não deve ser feita apenas por costume: verifique clientes, servidores intermediários e sistemas de CI que realmente usarão a credencial.

A parte pós-quântica não exige uma migração manual

O algoritmo mlkem768x25519-sha256 participa da troca de chaves da sessão, não substitui a chave pública cadastrada na conta. Clientes compatíveis poderão negociá-lo automaticamente; clientes antigos devem cair para outro mecanismo ainda aceito. Não é necessário procurar um novo botão de “chave pós-quântica” nas configurações do GitHub.

Checklist curto antes de outubro

  1. Liste os remotes e separe HTTPS de SSH.
  2. Confira a versão do OpenSSH ou da biblioteca usada por IDEs, CI e ferramentas Java.
  3. Teste a conexão com ssh -T [email protected].
  4. Atualize clientes antigos antes dos brownouts.
  5. Para novas chaves, prefira Ed25519; use RSA com pelo menos 3072 bits quando a compatibilidade exigir.
  6. Não revogue uma chave funcional sem confirmar como automações e máquinas de build dependem dela.

O ponto central é menos dramático do que parece: o GitHub não está banindo RSA. Está removendo uma assinatura baseada em SHA-1, aumentando o tamanho mínimo das novas chaves RSA e aposentando uma troca de chaves pouco usada. A ação correta começa por descobrir o que o cliente negocia, não por apagar credenciais às cegas.

Fontes

Leia também