{"id":101069,"date":"2021-08-20T22:22:44","date_gmt":"2021-08-20T20:22:44","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/reliz-openssh-8-7"},"modified":"2021-08-20T22:22:44","modified_gmt":"2021-08-20T20:22:44","slug":"reliz-openssh-8-7","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/news\/reliz-openssh-8-7","title":{"rendered":"Lan\u00e7amento do OpenSSH 8.7","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Ap\u00f3s quatro meses de desenvolvimento, o lan\u00e7amento do OpenSSH 8.7 foi apresentado, uma implementa\u00e7\u00e3o aberta do cliente e servidor para trabalhar com os protocolos SSH 2.0 e SFTP. <\/p>\n
Principais mudan\u00e7as: <\/p>\n
\n
No scp, foi adicionado um modo experimental de transfer\u00eancia de dados utilizando o protocolo SFTP em vez do tradicional protocolo SCP\/RCP. O SFTP utiliza m\u00e9todos de manipula\u00e7\u00e3o de nomes mais previs\u00edveis e n\u00e3o depende do tratamento de padr\u00f5es globais via shell no lado do host remoto, o que gera problemas de seguran\u00e7a. Para ativar o SFTP no scp, foi sugerida a op\u00e7\u00e3o \u2018-s\u2019, mas no futuro est\u00e1 previsto migrar para este protocolo como padr\u00e3o.\n
Na sftp-server, foram implementadas extens\u00f5es do protocolo SFTP para revelar caminhos ~\/ e ~user\/, o que \u00e9 necess\u00e1rio para o scp.\n
No utilit\u00e1rio scp, foi alterado o comportamento ao copiar arquivos entre dois hosts remotos (por exemplo, \u2018scp host-a:\/path host-b:\u2019), que agora por padr\u00e3o \u00e9 realizado atrav\u00e9s de um host local intermedi\u00e1rio, como ao especificar a op\u00e7\u00e3o \u2018-3\u2019. Essa abordagem permite evitar o envio desnecess\u00e1rio de credenciais ao primeiro host e a tripla interpreta\u00e7\u00e3o dos nomes de arquivos no shell (no lado do remetente, receptor e no sistema local), al\u00e9m de permitir que, usando SFTP, todos os m\u00e9todos de autentica\u00e7\u00e3o sejam utilizados ao se conectar a hosts remotos, e n\u00e3o apenas os m\u00e9todos n\u00e3o interativos. Para reverter o comportamento anterior, foi adicionada a op\u00e7\u00e3o \u2018-R\u2019.\n
No ssh, foi adicionada a configura\u00e7\u00e3o ForkAfterAuthentication, correspondente \u00e0 op\u00e7\u00e3o \u2018-f\u2019.\n
No ssh, foi adicionada a configura\u00e7\u00e3o StdinNull, correspondente \u00e0 op\u00e7\u00e3o \u2018-n\u2019.\n
No ssh, foi adicionada a configura\u00e7\u00e3o SessionType, por meio da qual se podem definir modos correspondentes \u00e0s op\u00e7\u00f5es \u2018-N\u2019 (sem sess\u00e3o) e \u2018-s\u2019 (subsystem).\n
No ssh-keygen, agora \u00e9 permitido especificar o intervalo de validade da chave nos arquivos com chaves.\n
No ssh-keygen, foi adicionada a op\u00e7\u00e3o \u2018-Oprint-pubkey\u2019 para exibir a chave p\u00fablica completa na assinatura sshsig.\n
No ssh e sshd, tanto o cliente quanto o servidor foram convertidos para utilizar um analisador de arquivo de configura\u00e7\u00e3o mais rigoroso, que usa regras semelhantes ao shell para tratamento de aspas, espa\u00e7os e caracteres de escape. O novo parser tamb\u00e9m n\u00e3o ignora suposi\u00e7\u00f5es feitas anteriormente, como o n\u00e3o envio de argumentos em op\u00e7\u00f5es (por exemplo, agora n\u00e3o \u00e9 permitido deixar a diretiva DenyUsers vazia), aspas n\u00e3o fechadas e a especifica\u00e7\u00e3o de v\u00e1rios caracteres \u2018=\u2019.\n
Ao usar registros DNS SSHFP para a verifica\u00e7\u00e3o de chaves, o ssh agora verifica todos os registros correspondentes, n\u00e3o apenas aqueles que cont\u00eam um tipo espec\u00edfico de assinatura digital.\n
No ssh-keygen ao gerar uma chave FIDO com a op\u00e7\u00e3o -Ochallenge para hashing, agora \u00e9 utilizada uma camada embutida, e n\u00e3o as ferramentas libfido2, permitindo o uso de sequ\u00eancias de challenge com tamanhos maiores ou menores que 32 bytes.\n
No sshd, ao processar a diretiva environment=\u2018\u2026\u2019 em arquivos authorized_keys, agora o primeiro correspond\u00eancia \u00e9 aceito e h\u00e1 uma limita\u00e7\u00e3o de 1024 nomes de vari\u00e1veis de ambiente. <\/ul>\n
Os desenvolvedores do OpenSSH tamb\u00e9m alertaram sobre a transi\u00e7\u00e3o para algoritmos obsoletos que utilizam hashes SHA-1, devido ao aumento da efic\u00e1cia de ataques de colis\u00e3o com prefixo definido (o custo para gerar uma colis\u00e3o \u00e9 estimado em cerca de 50 mil d\u00f3lares). Na pr\u00f3xima vers\u00e3o, ser\u00e1 desativada por padr\u00e3o a possibilidade de usar o algoritmo de assinatura digital com chave p\u00fablica \u00abssh-rsa\u00bb, que \u00e9 mencionado no RFC original do protocolo SSH e continua a ser amplamente utilizado na pr\u00e1tica. <\/p>\n
Para verificar o uso de ssh-rsa em seus sistemas, voc\u00ea pode tentar se conectar via ssh com a op\u00e7\u00e3o \u00ab-oHostKeyAlgorithms=-ssh-rsa\u00bb. No entanto, a desativa\u00e7\u00e3o padr\u00e3o das assinaturas digitais \u00abssh-rsa\u00bb n\u00e3o significa a rejei\u00e7\u00e3o total do uso de chaves RSA, pois al\u00e9m do SHA-1, o protocolo SSH permite o uso de outros algoritmos de hash. Em particular, al\u00e9m de \u00abssh-rsa\u00bb, ser\u00e1 poss\u00edvel continuar utilizando os pares \u00abrsa-sha2-256\u00bb (RSA\/SHA256) e \u00abrsa-sha2-512\u00bb (RSA\/SHA512). <\/p>\n