Lançamento do OpenSSH 8.5

Após cinco meses de desenvolvimento, é apresentado o lançamento do OpenSSH 8.5, uma implementação aberta de cliente e servidor para trabalhar nos protocolos SSH 2.0 e SFTP.

Os desenvolvedores do OpenSSH nos lembraram do próximo descomissionamento de algoritmos que usam hashes SHA-1 devido ao aumento da eficiência dos ataques de colisão com um determinado prefixo (o custo de selecionar uma colisão é estimado em aproximadamente US$ 50 mil). Em um dos próximos lançamentos, eles planejam desabilitar por padrão a capacidade de usar o algoritmo de assinatura digital de chave pública “ssh-rsa”, que é mencionado na RFC original para o protocolo SSH e continua difundido na prática.

Para testar o uso de ssh-rsa em seus sistemas, você pode tentar conectar via ssh com a opção “-oHostKeyAlgorithms=-ssh-rsa”. Ao mesmo tempo, desabilitar as assinaturas digitais “ssh-rsa” por padrão não significa um abandono total do uso de chaves RSA, pois além do SHA-1, o protocolo SSH permite a utilização de outros algoritmos de cálculo de hash. Em particular, além do “ssh-rsa”, continuará a ser possível utilizar os pacotes “rsa-sha2-256” (RSA/SHA256) e “rsa-sha2-512” (RSA/SHA512).

Para facilitar a transição para novos algoritmos, o OpenSSH 8.5 inclui a configuração UpdateHostKeys, que migra automaticamente os clientes para algoritmos mais seguros. Essa configuração habilita uma extensão de protocolo especial, "hostkeys@openssh.com", que permite ao servidor informar ao cliente todas as chaves de host disponíveis após a autenticação. O cliente pode armazenar essas chaves em seu arquivo ~/.ssh/known_hosts, o que permite atualizações de chaves de host e simplifica a rotação de chaves. servidor.

O uso de UpdateHostKeys é limitado por diversas advertências que podem ser removidas no futuro: a chave deve ser referenciada no UserKnownHostsFile e não usada no GlobalKnownHostsFile; a chave deve estar presente com apenas um nome; um certificado de chave de host não deve ser usado; emknown_hosts máscaras por nome de host não devem ser usadas; a configuração VerifyHostKeyDNS deve estar desabilitada; O parâmetro UserKnownHostsFile deve estar ativo.

Os algoritmos recomendados para migração incluem rsa-sha2-256/512 baseado em RFC8332 RSA SHA-2 (suportado desde OpenSSH 7.2 e usado por padrão), ssh-ed25519 (suportado desde OpenSSH 6.5) e ecdsa-sha2-nistp256/384/521 baseado no RFC5656 ECDSA (suportado desde OpenSSH 5.7).

Outras mudanças:

• Mudanças de segurança:
  • Uma vulnerabilidade causada pela liberação de uma área de memória já liberada (liberação dupla) foi corrigida no ssh-agent. O problema está presente desde o lançamento do OpenSSH 8.2 e pode ser potencialmente explorado se um invasor tiver acesso ao soquete ssh-agent no sistema local. O que torna a exploração mais difícil é que apenas o root e o usuário original têm acesso ao soquete. O cenário de ataque mais provável é que o agente seja redirecionado para uma conta controlada pelo invasor ou para um host onde o invasor tenha acesso root.
  • sshd adicionou proteção contra a passagem de parâmetros muito grandes com o nome de usuário para o subsistema PAM, o que permite bloquear vulnerabilidades nos módulos do sistema PAM (Pluggable Authentication Module). Por exemplo, a mudança impede que o sshd seja usado como um vetor para explorar uma vulnerabilidade raiz recentemente descoberta no Solaris (CVE-2020-14871).
• Potencialmente quebrando alterações de compatibilidade:
  • Um método experimental de troca de chaves resistente a ataques de força bruta em um computador quântico foi redesenhado em ssh e sshd. Computadores quânticos são muito mais rápidos na resolução do problema de fatorar um número natural em fatores primos, que fundamenta algoritmos modernos de criptografia assimétrica e não pode ser resolvido de forma eficaz em processadores clássicos. O método utilizado baseia-se no algoritmo NTRU Prime, desenvolvido para criptosistemas pós-quânticos, e no método de troca de chaves por curva elíptica X25519. Em vez de sntrup4591761x25519-sha512@tinyssh.org, o método agora é identificado como sntrup761x25519-sha512@openssh.com (o algoritmo sntrup4591761 foi substituído por sntrup761).
  • Em ssh e sshd, a ordem em que os algoritmos de assinatura digital suportados são anunciados foi alterada. O ED25519 agora é oferecido primeiro em vez do ECDSA.
  • Em ssh e sshd, a configuração dos parâmetros de qualidade de serviço TOS/DSCP para sessões interativas agora é feita antes de estabelecer uma conexão TCP.
  • ssh e sshd deixaram de oferecer suporte à cifra rijndael-cbc@lysator.liu.se, que é idêntica à aes256-cbc e era usada antes da RFC-4253.
  • Por padrão, o parâmetro CheckHostIP está desabilitado, cujo benefício é insignificante, mas seu uso complica significativamente a rotação de chaves para hosts atrás de balanceadores de carga.
• As configurações PerSourceMaxStartups e PerSourceNetBlockSize foram adicionadas ao sshd para limitar a intensidade de inicialização de manipuladores com base no endereço do cliente. Esses parâmetros permitem controlar com mais precisão o limite de inicialização de processos, em comparação com a configuração geral de MaxStartups.
• Uma nova configuração LogVerbose foi adicionada ao ssh e sshd, o que permite aumentar à força o nível de informações de depuração despejadas no log, com a capacidade de filtrar por modelos, funções e arquivos.
• No SSH, ao aceitar uma nova chave de host, todos os nomes de host são exibidos e Endereços IP, associado à chave.
• ssh permite que a opção UserKnownHostsFile=none desabilite o uso do arquivoknown_hosts ao identificar chaves de host.
• Uma configuração KnownHostsCommand foi adicionada ao ssh_config para ssh, permitindo que você obtenha dados deknown_hosts a partir da saída do comando especificado.
• Adicionada uma opção PermitRemoteOpen ao ssh_config para ssh para permitir que você restrinja o destino ao usar a opção RemoteForward com SOCKS.
• No ssh para chaves FIDO, uma solicitação repetida de PIN é fornecida no caso de uma falha na operação de assinatura digital devido a um PIN incorreto e ao usuário não ser solicitado a fornecer um PIN (por exemplo, quando os dados biométricos corretos não puderem ser obtidos e o dispositivo voltou para a entrada manual do PIN).
• No sshd, o mecanismo de isolamento de processos baseado em seccomp-bpf na plataforma Linux Adicionado suporte para chamadas de sistema adicionais.
• O utilitário contrib/ssh-copy-id foi atualizado.

Fonte: opennet.ru