O GitHub endureceu o transporte SSH de github.com e do GitHub Enterprise Cloud com Data Residency em um anúncio publicado em 22 de setembro. A partir de 14 de outubro de 2026, toda chave RSA nova carregada no GitHub precisa ter no mínimo 3072 bits, tanto para autenticação quanto para assinatura de commits. Em paralelo, dois algoritmos considerados fracos entram em rota de desativação: a assinatura ssh-rsa, que combina RSA com SHA-1, e a troca de chaves diffie-hellman-group-exchange-sha256. O impacto concentra-se em quem acessa repositórios por SSH, com destaque para pipelines de CI, agentes Jenkins e automações construídas sobre bibliotecas antigas; quem usa remotes em https:// não sofre nenhum efeito. A ação prioritária é inventariar cada ponto da infraestrutura que fala SSH com o GitHub e testá-lo antes da primeira janela de falha programada.
O que muda no SSH
As alterações têm três frentes. A primeira é o piso de tamanho para chaves RSA: uploads feitos depois da data-limite são rejeitados se forem menores que 3072 bits. A segunda é a remoção do SHA-1 do caminho de assinatura, um hash quebrado há quase duas décadas que ainda sobrevive em clientes antigos. A terceira é a aposentadoria do diffie-hellman-group-exchange-sha256, método de troca de chaves lento, pouco usado e que, na avaliação do próprio GitHub, poderia ser quebrado por avanços em computação quântica. No lugar dele, a plataforma passa a oferecer um mecanismo pós-quântico moderno, detalhado adiante.
Há uma distinção que evita pânico desnecessário: ssh-rsa é ao mesmo tempo um tipo de chave e um tipo de assinatura. Toda chave RSA carrega o tipo ssh-rsa, mas pode assinar com SHA-256 ou SHA-512, os tipos rsa-sha2-256 e rsa-sha2-512. O que o GitHub remove é a assinatura com SHA-1, não a chave em si. Quem usa um cliente que negocia SHA-2, comportamento padrão das versões modernas do OpenSSH, mantém a mesma chave sem precisar regenerá-la. O risco real está nos cantos da infraestrutura onde ninguém olha: imagens de contêiner congeladas, agentes de build sem manutenção e bibliotecas SSH embutidas em ferramentas internas — a mesma superfície negligenciada que torna os segredos no CI/CD um vetor persistente de vazamento.
Calendário e janelas de teste
O cronograma publicado pelo GitHub usa brownouts, janelas deliberadas em que os algoritmos velhos param de funcionar por um período, para expor dependências antes da remoção definitiva. A plataforma programou brownouts em 4 de novembro e 9 de dezembro de 2026, cobrindo tanto a assinatura ssh-rsa quanto o diffie-hellman-group-exchange-sha256. A lógica é explícita: é melhor descobrir a incompatibilidade numa data escolhida pelo fornecedor do que no dia da remoção final. O changelog também lista uma remoção definitiva em janeiro, mas com o ano impresso de forma inconsistente na própria página; a referência prática de planejamento são os brownouts, não a última linha do quadro.
No GitHub Enterprise Server, as mudanças entram na versão 3.25, exceto o novo mecanismo pós-quântico, que chega antes, na versão 3.24. Quem administra instâncias auto-hospedadas precisa alinhar o upgrade do servidor com o calendário de atualização dos clientes internos, senão troca um problema de compatibilidade por outro. Usuários do protocolo Git não autenticado no Enterprise Server também entram no escopo.
Onde vai quebrar primeiro
O laptop do desenvolvedor raramente é o problema. As falhas concentram-se em quatro pontos. Primeiro, imagens de CI antigas, em que o cliente SSH é simplesmente aquele que a imagem base trouxe. Segundo, agentes Jenkins e ferramentas Java que usam JSch no lugar do binário ssh do sistema, um caminho de código que precisa ser testado separadamente. Terceiro, bibliotecas embutidas como libssh2 e implementações Go antigas dentro de produtos internos e bots de integração. Quarto, appliances e proxies com perfis criptográficos travados por política de segurança. Quando um desses pontos quebra, o sintoma parece incidente de rede: clones, pushes e chamadas de API por esse caminho param de responder, e a equipe perde tempo investigando firewall em vez de algoritmo. O primeiro sinal quase sempre aparece em job de build agendado, não em pessoa.
Mudanças silenciosas de plataforma expõem dívidas de acesso acumuladas por anos. O GitHub tem aplicado a mesma lógica defensiva em outras frentes, como a prova de presença contra sessões roubadas: elevar o piso criptográfico padrão protege a maioria e penaliza apenas quem se recusou a migrar. Desta vez, o piso é o SHA-1.
Versões mínimas e diagnóstico
O changelog publica a lista de softwares comuns e a versão mínima para suportar RSA com SHA-2 de forma robusta na configuração padrão:
| Software | Versão mínima |
|---|---|
| OpenSSH | 7.2p1 |
| JSch | 0.1.66 (fork mwiede) |
| TeamCity | 2021.2.3 |
| Go SSH | 0.16.0 |
| libssh2 | 1.11.0 |
| PuTTY | 0.82 |
O diagnóstico cabe em uma tarde de trabalho e segue uma ordem fixa:
- Rodar
git remote -vnos repositórios ativos e listar quais usamgit@oussh://em vez de https. - Executar
ssh -Vem cada runner, agente e contêiner de build; tudo abaixo do OpenSSH 7.2 entra na fila de atualização. - Testar cada caminho com os algoritmos velhos desativados no cliente, negando
ssh-rsaem PubkeyAcceptedAlgorithms ediffie-hellman-group-exchange-sha256em KexAlgorithms. Se o acesso funciona nesse modo, o brownout não afetará aquele ponto. - Revisar arquivos de configuração em
/etc/ssh/ssh_config.de configs embutidos por KexAlgorithms, HostKeyAlgorithms e PubkeyAcceptedAlgoritmos fixados no tempo. - Auditar deploy keys, chaves de machine users e certificados SSH por organização, revogando o que não tem dono.
Para chaves novas, a recomendação do próprio GitHub é Ed25519 sempre que possível; se a compatibilidade com outros serviços exigir RSA, gerar com pelo menos 3072 bits. Chaves RSA existentes continuam válidas sem regeneração, desde que o cliente assine com SHA-2 — condição que o teste do passo 3 comprova por caminho, não por suposição.
Pós-quântico entra no Git
Na mesma data de 14 de outubro, o GitHub habilita o mlkem768x25519-sha256 como troca de chaves para sessões SSH em github.com e no Enterprise Cloud com Data Residency, exceto na região dos Estados Unidos. O método combina ML-KEM com X25519 em modo híbrido e não exige mudança de configuração: clientes modernos passam a preferi-lo automaticamente, e clientes antigos caem para mecanismos anteriores sem interrupção. O ML-KEM é definido pelo FIPS 203 publicado em 13 de agosto de 2024 pelo NIST, o padrão de encapsulamento de chaves em retículos modulares que fundamenta a migração pós-quântica da indústria. A mensagem para arquitetos é direta: a híbrida pós-quântica deixou de ser item de roadmap e virou comportamento padrão de plataforma de código. Ignorar a onda agora significa reeditar a mesma crise de compatibilidade que o SHA-1 está causando, só que na direção oposta.
Ações prioritárias P1 e P2
P1, antes da janela de novembro: concluir o inventário de remotes SSH e clientes; atualizar ou substituir tudo que estiver abaixo das versões mínimas da tabela; rodar o teste sem algoritmos legados em cada runner com as credenciais reais do job, não com a conta do engenheiro; e padronizar a geração de chaves novas em Ed25519, com RSA de 3072 bits ou mais como exceção documentada.
P2, até dezembro: atualizar bibliotecas JSch, libssh2 e Go SSH embutidas em ferramentas internas; planejar o upgrade do GitHub Enterprise Server para 3.25 com o ML-KEM da 3.24 já validado; tratar o segundo brownout como ensaio geral da remoção definitiva; e monitorar os logs de CI durante as janelas programadas para capturar erros de negociação que só aparecem sob carga. Quem entrega os dois blocos chega a 2027 sem dependência de SHA-1 em nenhum caminho que toca o repositório — e com troca de chaves pós-quântica ativa sem ter escrito uma linha de configuração.