Após cinco meses de desenvolvimento lançamento , uma implementação aberta de cliente e servidor para trabalhar com os protocolos SSH 2.0 e SFTP.
Principais mudanças:
- No ssh e sshd, foi adicionada a suporte experimental para um método de troca de chaves resistente a ataques de computadores quânticos. Computadores quânticos resolvem a tarefa de fatoração de números inteiros em fatores primos de forma radicalmente mais rápida, o que é a base para os algoritmos de criptografia assimétrica modernos e é efetivamente insolúvel em processadores clássicos. O método proposto é baseado no algoritmo (função ntrup4591761), desenvolvido para sistemas de criptografia pós-quântica, e no método de troca de chaves baseado em curvas elípticas X25519;
- No sshd, nas diretrizes ListenAddress e PermitOpen, o suporte para a sintaxe obsoleta "host/port", implementada em 2001 como alternativa a "host:port" para simplificar o trabalho com IPv6, foi descontinuado. Nas condições atuais, a sintaxe para IPv6 se estabeleceu como "[::1]:22", e "host/port" é frequentemente confundida com a especificação da sub-rede (CIDR);
- No ssh, ssh-agent e ssh-add, foi implementado o suporte a chaves em tokens PKCS#11;
- No ssh-keygen, o tamanho padrão da chave RSA foi aumentado para 3072 bits, de acordo com as novas recomendações do NIST;
- No ssh, é permitida a configuração "PKCS11Provider=none" para sobrepor a diretiva PKCS11Provider definida em ssh_config;
- No sshd, foi garantido o registro em log das situações em que a conexão é encerrada ao tentar executar comandos bloqueados pela restrição "ForceCommand=internal-sftp" em sshd_config;
- No ssh, ao exibir o prompt para confirmação da aceitação de uma nova chave de host, em vez da resposta "yes", agora é reconhecido o fingerprint correto da chave (em resposta ao convite para confirmar a conexão, o usuário pode copiar o hash de referência recebido separadamente para evitar a comparação manual);
- No ssh-keygen, foi garantido o aumento automático do número de sequência no certificado ao criar assinaturas digitais para vários certificados na linha de comando;
- No scp e sftp, foi adicionada uma nova opção "-J", equivalente à configuração ProxyJump;
- No ssh-agent, ssh-pkcs11-helper e ssh-add, foi adicionada a manipulação da opção de linha de comando "-v" para aumentar a informatividade da saída (quando especificada, esta opção é passada aos processos filhos, por exemplo, quando ssh-pkcs11-helper é chamado a partir do ssh-agent);
- A opção «-T» foi adicionada ao ssh-add para testar a adequação das chaves no ssh-agent para operações de criação e verificação de assinaturas digitais;
- O sftp-server implementou o suporte à extensão do protocolo «lsetstat at openssh.com», que adiciona suporte à operação SSH2_FXP_SETSTAT para SFTP, mas sem seguir links simbólicos;
- O sftp adicionou a opção «-h» para executar comandos chown/chgrp/chmod com solicitações que não usam links simbólicos;
- O sshd agora garante a definição da variável de ambiente $SSH_CONNECTION para PAM;
- Para o sshd, o modo de correspondência «Match final» foi adicionado ao ssh_config, semelhante ao «Match canonical», mas sem exigir a normalização do nome do host;
- O sftp adicionou suporte ao prefixo ‘@’ para desativar a tradução da saída de comandos executados em modo batch;
- Ao exibir o conteúdo do certificado com o comando
«ssh-keygen -Lf /path/certificate», agora exibe o algoritmo utilizado pela autoridade certificadora para certificar o certificado; - Melhorado o suporte ao ambiente Cygwin, como a comparação de nomes de grupos e usuários sem considerar a distinção entre maiúsculas e minúsculas. O processo sshd na porta para Cygwin foi alterado para cygsshd para evitar conflitos com a porta OpenSSH fornecida pela Microsoft;
- Adicionada a capacidade de compilação com a versão experimental do OpenSSL 3.x;
- Eliminada (CVE-2019-6111) na implementação da ferramenta scp, permitindo sobrescrever arquivos arbitrários no diretório de destino no lado do cliente ao se conectar a um servidor controlado por um invasor. O problema está que, ao usar o scp, o servidor decide quais arquivos e diretórios enviar ao cliente, enquanto o cliente apenas verifica a validade dos nomes de objetos devolvidos. A verificação do lado do cliente está limitada apenas ao bloqueio da saída do diretório atual («../»), mas não considera a transferência de arquivos com nomes diferentes dos originalmente solicitados. No caso de cópias recursivas (-r), além dos nomes de arquivos, os nomes de subdiretórios também podem ser manipulados dessa forma. Por exemplo, ao copiar arquivos para o diretório pessoal, o servidor que está sob controle do invasor pode fornecer, em vez dos arquivos solicitados, arquivos com nomes .bash_aliases ou .ssh/authorized_keys, e estes serão salvos pela ferramenta scp no diretório pessoal do usuário.
Na nova edição, a ferramenta scp agora inclui uma verificação de conformidade entre os nomes de arquivos solicitados e os retornados pelo servidor, realizada no lado do cliente. Isso pode gerar problemas com o processamento de máscaras, uma vez que os caracteres de máscaras podem ser tratados de forma diferente no lado do servidor e no cliente. Para o caso de o cliente parar de aceitar arquivos devido a tais diferenças, foi adicionada a opção "-T" que permite desativar a verificação no lado do cliente. Para corrigir completamente o problema, uma reformulação conceitual do protocolo scp seria necessária, pois este já está desatualizado. Assim, é recomendável usar protocolos mais modernos, como sftp e rsync.
Fonte: opennet.ru
