Após quatro meses de desenvolvimento, foi apresentado o lançamento do OpenSSH 8.7, uma implementação aberta de cliente e servidor para trabalhar nos protocolos SSH 2.0 e SFTP.
Grandes mudanças:
- Um modo experimental de transferência de dados foi adicionado ao scp usando o protocolo SFTP em vez do protocolo SCP/RCP tradicional. O SFTP usa métodos de tratamento de nomes mais previsíveis e não usa processamento shell de padrões glob no outro host, o que cria problemas de segurança. Para habilitar o SFTP no scp, o sinalizador “-s” foi proposto, mas no futuro está planejado mudar para este protocolo por padrão.
- sftp-server implementa extensões ao protocolo SFTP para expandir os caminhos ~/ e ~user/, que são necessários para o scp.
- O utilitário scp mudou o comportamento ao copiar arquivos entre dois hosts remotos (por exemplo, “scp host-a:/path host-b:”), o que agora é feito por padrão através de um host local intermediário, como ao especificar o “ -3” bandeira. Essa abordagem permite evitar a passagem de credenciais desnecessárias para o primeiro host e a interpretação tripla dos nomes dos arquivos no shell (na origem, no destino e no lado do sistema local) e, ao usar SFTP, permite usar todos os métodos de autenticação ao acessar remotamente hosts, e não apenas métodos não interativos. A opção “-R” foi adicionada para restaurar o comportamento antigo.
- Adicionada configuração ForkAfterAuthentication ao ssh correspondente ao sinalizador "-f".
- Adicionada configuração StdinNull ao ssh, correspondente ao sinalizador "-n".
- Uma configuração SessionType foi adicionada ao ssh, por meio da qual você pode definir modos correspondentes aos sinalizadores “-N” (sem sessão) e “-s” (subsistema).
- ssh-keygen permite especificar um intervalo de validade de chave em arquivos de chave.
- Adicionado sinalizador "-Oprint-pubkey" ao ssh-keygen para imprimir a chave pública completa como parte da assinatura sshsig.
- No ssh e no sshd, tanto o cliente quanto o servidor foram movidos para usar um analisador de arquivo de configuração mais restritivo que usa regras semelhantes ao shell para lidar com aspas, espaços e caracteres de escape. O novo analisador também não ignora suposições feitas anteriormente, como a omissão de argumentos nas opções (por exemplo, a diretiva DenyUsers não pode mais ser deixada em branco), aspas não fechadas e a especificação de vários caracteres =.
- Ao usar registros DNS SSHFP ao verificar chaves, o ssh agora verifica todos os registros correspondentes, não apenas aqueles que contêm um tipo específico de assinatura digital.
- No ssh-keygen, ao gerar uma chave FIDO com a opção -Ochallenge, a camada interna agora é usada para hash, em vez de libfido2, que permite o uso de sequências de desafio maiores ou menores que 32 bytes.
- No sshd, ao processar diretivas de ambiente="..." em arquivos autorizados_keys, a primeira correspondência agora é aceita e há um limite de 1024 nomes de variáveis de ambiente.
Os desenvolvedores do OpenSSH também alertaram sobre a decomposição de algoritmos usando hashes SHA-1 devido ao aumento da eficiência dos ataques de colisão com um determinado prefixo (o custo de seleção de uma colisão é estimado em aproximadamente 50 mil dólares). Na próxima versão, planejamos desabilitar por padrão a capacidade de usar o algoritmo de assinatura digital de chave pública "ssh-rsa", que foi mencionado na RFC original para o protocolo SSH e continua sendo amplamente utilizado 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 anteriormente tinha a configuração UpdateHostKeys habilitada por padrão, que permite aos clientes mudar 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).
Fonte: opennet.ru