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 tem a configuração UpdateHostKeys habilitada por padrão, que permite que os clientes mudem automaticamente para algoritmos mais confiáveis. Usando esta configuração, uma extensão de protocolo especial é habilitada “[email protegido]", permitindo ao servidor, após a autenticação, informar ao cliente sobre todas as chaves de host disponíveis. O cliente pode refletir essas chaves em seu arquivo ~/.ssh/known_hosts, o que permite que as chaves do host sejam atualizadas e facilita a alteração das chaves no 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:
    • В ssh и sshd переработан экспериментальный метод обмена ключами, стойкий к подбору на квантовом компьютере. Квантовые компьютеры кардинально быстрее решают задачу разложения натурального числа на простые множители, которая лежит в основе современных асимметричных алгоритмов шифрования и эффективно не решаема на классических процессорах. Используемый метод основан на алгоритме NTRU Prime, разработанном для постквантумных криптосистем, и методе обмена ключами на базе эллиптических кривых X25519. Вместо [email protegido] метод теперь идентифицируется как [email protegido] (o algoritmo sntrup4591761 foi substituído pelo 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.
    • O suporte à cifra foi descontinuado em ssh e sshd [email protegido], que é idêntico ao aes256-cbc e foi usado antes da aprovação do 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 e endereços IP associados à chave são mostrados.
  • 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).
  • sshd adiciona suporte para chamadas de sistema adicionais ao mecanismo de isolamento de processo baseado em seccomp-bpf no Linux.
  • O utilitário contrib/ssh-copy-id foi atualizado.

Fonte: opennet.ru

Adicionar um comentário