Por que o GitHub de repente rejeitou chaves SSH: o arquivo `.pub` que sumiu

• O git pull no GitHub de repente passou a falhar em um notebook que não havia sido alterado, mas a autenticação voltou a funcionar depois de gerar o arquivo .pub correspondente à chave privada
• Com o arquivo .pub, o OpenSSH apresenta primeiro a chave pública, recebe a aprovação e então assina; sem ele, envia imediatamente uma solicitação de autenticação assinada
• Ambos os fluxos estão de acordo com a RFC 4252 e um sshd comum aceita os dois, mas o frontend SSH do GitHub naquele momento aparentemente não aceitava solicitações assinadas diretamente
• Em 12 testes controlados, as 6 tentativas sem o arquivo .pub foram todas rejeitadas, e as 6 com o arquivo foram todas bem-sucedidas
• A mudança no banner do servidor sugere uma possível alteração no software do lado do servidor, mas como a causa exata não foi confirmada, é mais seguro manter também o arquivo de chave pública correspondente

---

Falha repentina de autenticação e solução

• No notebook principal, o git pull parou com o erro Permission denied (publickey)
  • A chave em questão ainda estava cadastrada no GitHub
  • Em um notebook que usava outra chave, o mesmo repositório podia ser baixado normalmente
• Não foi encontrado nenhum problema na chave nem na configuração do cliente
  • openssl rsa -check retornava RSA key ok
  • Estava sendo usado o algoritmo de assinatura mais recente, rsa-sha2-512
  • Não havia problema em ~/.ssh/config, e a página de status do GitHub também estava normal
• Após a reinstalação, o arquivo de chave pública correspondente a ~/.ssh/github_rsa havia desaparecido, e a autenticação voltou a funcionar ao gerá-lo com o seguinte comando

ssh-keygen -y -f ~/.ssh/github_rsa > ~/.ssh/github_rsa.pub

• Nos testes controlados, as 6 tentativas sem o arquivo .pub falharam, e as 6 com ele foram todas bem-sucedidas

O fluxo de autenticação muda conforme o arquivo .pub

• O OpenSSH usa fluxos diferentes de autenticação por chave pública dependendo da existência do arquivo .pub
  • Se o arquivo existir, ele primeiro apresenta a chave pública, espera a aprovação do servidor e depois assina
  • Se houver apenas a chave privada, ele pula essa verificação prévia e envia imediatamente uma solicitação de autenticação totalmente assinada
• As duas formas são permitidas pela RFC 4252, e um sshd comum aceita ambas
• Naquele momento, o GitHub rejeitava solicitações de chave pública assinadas diretamente, mas não foi possível confirmar se houve de fato alguma mudança do lado do GitHub
  • O banner do servidor nos logs de depuração aparecia como 6a2c000, e não mais no formato antigo babeld-<hash>
  • A possibilidade de um novo software de servidor rejeitar solicitações assinadas diretamente permanece apenas como hipótese
• Para evitar o mesmo problema, é preciso manter junto o arquivo .pub correspondente à chave privada

[GN⁺]

Opiniões no Lobste.rs

• Estou passando pelo mesmo problema nas últimas 4 horas, e ele já foi registrado em https://www.githubstatus.com/incidents/g40zcbvchny4

• Algumas semanas atrás troquei minha chave SSH, mas não apaguei o antigo arquivo .pub que estava sendo ignorado pelo Git; mesmo ao conectar com a chave nova, continuava falhando
  Só depois de ativar várias opções de depuração descobri que o cliente SSH estava enviando a impressão digital antiga, e eu nem sabia que o OpenSSH lia o arquivo .pub — sempre achei que ele fosse totalmente desnecessário

• Hoje meu servidor de CI teve a mesma falha e de repente não conseguia mais se conectar ao github.com
  Voltou a funcionar depois que substituí a chave pela chave ed25519 correta, mas essa chave também não tem um arquivo .pub correspondente, então não sei por que isso resolveu

  • Quando a chave parou de funcionar de repente, primeiro temi um incidente de comprometimento, então fico aliviado que agora o próprio GitHub parece estar lidando com isso

• Tive o mesmo problema hoje, e até onde eu sei o GitHub não anunciou que planejava mudar o comportamento da autenticação SSH

  • Não parece ter sido uma mudança planejada

• Perdi tanto a senha quanto a chave de recuperação e passei pelo procedimento de recuperação de conta baseada em chave SSH, mas o GitHub expirou essa chave SSH e acabei perdendo completamente o acesso à conta

• Acho que faz 7 ou 8 anos que não mantenho um arquivo .pub, então espero que isso seja corrigido antes da próxima vez que eu usar o GitHub

  • O arquivo de chave pública pode ser recriado facilmente, e o comando correspondente também aparece no post original

• Se os dois fluxos de autenticação são válidos, fico me perguntando por que o fluxo de descoberta de chave existe
  Parece só causar esse tipo de comportamento estranho e, se a chave pública pode ser gerada a partir da chave privada de qualquer forma, o SSH poderia simplesmente fazer isso automaticamente

  • É uma funcionalidade para situações em que a chave privada está criptografada ou armazenada em um token de segurança de hardware e não pode ser usada imediatamente
    O SSH primeiro verifica quais chaves podem funcionar no servidor, para que o usuário não precise descriptografar desnecessariamente uma chave que certamente falhará na autenticação
    Esse comportamento também tem efeitos colaterais curiosos, como https://github.com/FiloSottile/whoami.filippo.io, então também seria necessário permitir um modo em que o servidor só possa tentar a autenticação se já conhecer antecipadamente a chave pública do cliente, para o caso de o usuário se conectar por engano ao servidor errado

• Minha conta corporativa do Office 365 também parou de funcionar de repente hoje pela primeira vez em 5 anos
  Fico pensando se houve algum comprometimento na Microsoft e eles colocaram salt em tudo de novo, ou se isso aconteceu só com usuários europeus por causa da recente votação do Chat Control 1.0

  • O serviço de encerramento de conexão do GitHub e a autenticação de contas M365 não têm absolutamente nenhuma relação, e tenho 99,999% de certeza de que é coincidência
    Sou uma das duas pessoas que conheço que já trabalharam tanto em Git Systems do GitHub quanto na suíte de produtos Office/M365 da Microsoft, então estou bem qualificado para afirmar isso
    Mesmo que a causa fosse uma mesma mudança de política ou de tecnologia aplicada aos dois serviços, são sistemas isolados, então a chance de terem sido implantados no mesmo dia é extremamente baixa