OpenSSH 8.2 adiciona FIDO/U2F e endurece autenticação SSH

OpenSSH 8.2 chegou com suporte a autenticadores FIDO/U2F, levando chaves apoiadas por hardware para o fluxo cotidiano de SSH. A versão adiciona os tipos de chave pública ecdsa-sk e ed25519-sk, além de tipos correspondentes para certificados, e permite gerar credenciais com ssh-keygen desde que o token esteja conectado.¹

O efeito prático é claro: uma chave privada copiada do disco deixa de ser suficiente para autenticar. O material sensível fica preso ao dispositivo físico, e a operação normalmente exige toque ou confirmação no token. Para administradores, SREs e equipes que acessam servidores críticos, isso aproxima SSH do padrão de autenticação forte já adotado em logins web.

Chave no hardware muda o modelo de ameaça

Chaves SSH tradicionais são seguras quando bem protegidas, mas continuam sendo arquivos. Elas podem ser expostas por backup mal configurado, malware local, cópia para máquinas temporárias, permissões erradas ou agentes encaminhados de forma descuidada. Passphrases ajudam, mas não removem o risco de exfiltração.

Com FIDO/U2F, o token participa da assinatura sem liberar a chave privada exportável. Um atacante que obtém o arquivo de chave associado não consegue usá-lo sozinho. Ele também precisa do dispositivo físico e, em muitos casos, da interação explícita do usuário. Isso melhora a defesa contra roubo silencioso de credenciais.

OpenSSH inclui ainda um ssh-sk-helper, usado para isolar bibliotecas de middleware de token em outro espaço de processo.¹ Esse detalhe é importante: integração com hardware e bibliotecas externas amplia superfície de ataque, então separar responsabilidades reduz impacto de falhas.

Adoção exige empacotamento e política

O suporte não significa que todas as distribuições entreguem a mesma experiência imediatamente. O middleware interno depende de libfido2 e precisa ser habilitado no build portátil. Distribuições, imagens base e hosts gerenciados devem ser verificados antes de uma política corporativa exigir esse tipo de chave.

Também há decisões operacionais. Quais usuários precisam de tokens? Como registrar chaves em authorized_keys? O toque físico será obrigatório? Resident keys fazem sentido? Como lidar com perda de dispositivo, rotação, break glass e acesso de automações? Segurança forte sem processo de recuperação vira risco de disponibilidade.

Para máquinas pessoais e acessos administrativos, o ganho é atraente. Para automação não interativa, a solução precisa ser desenhada com cuidado. CI, deploy e agentes de configuração normalmente exigem identidades de máquina, escopos restritos e segregação de permissões, não simplesmente o mesmo modelo usado por humanos.

SHA-1 entra em fase de pressão final

OpenSSH 8.2 também reforça o afastamento de algoritmos baseados em SHA-1. As notas da versão avisam sobre a futura desativação do algoritmo de assinatura ssh-rsa por padrão e removem ssh-rsa da lista aceita para assinaturas de certificados, usando rsa-sha2-512 como padrão em novas assinaturas de CA com RSA.¹

Esse ponto afeta ambientes antigos. Servidores, appliances e clientes desatualizados podem depender de algoritmos que já não são aceitáveis para uma postura moderna. Equipes precisam testar compatibilidade, renovar chaves, atualizar appliances e evitar que exceções de criptografia virem normalidade.

O lançamento de OpenSSH 8.2 combina duas mensagens: autenticação humana deve se aproximar de hardware resistente a roubo, e criptografia legada precisa sair do caminho. Para operações críticas, a versão é menos uma atualização de conveniência e mais um convite a revisar o modelo inteiro de acesso remoto.