{"id":42941,"date":"2020-02-17T14:41:56","date_gmt":"2020-02-17T11:41:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/reliz-openssh-8-2-c-podderzhkoj-tokenov-dvuhfaktornoj-autentifikaczii-fido-u2f"},"modified":"2020-02-17T14:41:56","modified_gmt":"2020-02-17T11:41:56","slug":"reliz-openssh-8-2-c-podderzhkoj-tokenov-dvuhfaktornoj-autentifikaczii-fido-u2f","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/reliz-openssh-8-2-c-podderzhkoj-tokenov-dvuhfaktornoj-autentifikaczii-fido-u2f","title":{"rendered":"Lan\u00e7amento do OpenSSH 8.2 com suporte para tokens de autentica\u00e7\u00e3o de dois fatores FIDO\/U2F","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ap\u00f3s quatro meses de desenvolvimento apresentado<\/a><\/noindex> lan\u00e7amento OpenSSH 8.2<\/a><\/noindex>, uma implementa\u00e7\u00e3o aberta de cliente e servidor para trabalhar com os protocolos SSH 2.0 e SFTP. <\/p>\n

A principal melhoria na vers\u00e3o OpenSSH 8.2 foi a adi\u00e7\u00e3o do suporte \u00e0 autentica\u00e7\u00e3o em duas etapas utilizando dispositivos compat\u00edveis com o protocolo U2F<\/a><\/noindex>, desenvolvido pela alian\u00e7a FIDO<\/a><\/noindex>. O U2F permite a cria\u00e7\u00e3o de tokens de hardware de baixo custo para confirmar a presen\u00e7a f\u00edsica do usu\u00e1rio, sendo compat\u00edveis com USB, Bluetooth ou NFC. Esses dispositivos est\u00e3o sendo promovidos como um meio de autentica\u00e7\u00e3o em duas etapas em sites, j\u00e1 s\u00e3o suportados pelos principais navegadores e s\u00e3o fabricados por diversas empresas, incluindo Yubico, Feitian, Thetis e Kensington.<\/p>\n

Para interagir com dispositivos que confirmam a presen\u00e7a do usu\u00e1rio, o OpenSSH adicionou novos tipos de chaves 'ecdsa-sk' e 'ed25519-sk', que utilizam algoritmos de assinatura digital ECDSA e Ed25519, em conjunto com a hash SHA-256. Os procedimentos de intera\u00e7\u00e3o com os tokens foram movidos para uma biblioteca intermedi\u00e1ria, que \u00e9 carregada de maneira similar \u00e0 biblioteca para suporte a PKCS#11 e atua como uma camada sobre a biblioteca. libfido2<\/a><\/noindex>, fornecendo recursos para comunica\u00e7\u00e3o com tokens atrav\u00e9s do USB (suportando os protocolos FIDO U2F\/CTAP 1 e FIDO 2.0\/CTAP 2). A biblioteca intermedi\u00e1ria libsk-libfido2, desenvolvida pelos criadores do OpenSSH, \u00e9 integrada ao conjunto principal da libfido2, assim como inclu\u00edda<\/a><\/noindex> o driver HID para OpenBSD.<\/a><\/noindex> Para autentica\u00e7\u00e3o e gera\u00e7\u00e3o de chaves, \u00e9 necess\u00e1rio especificar na configura\u00e7\u00e3o o par\u00e2metro \u2018SecurityKeyProvider\u2019 ou definir a vari\u00e1vel de ambiente SSH_SK_PROVIDER, indicando o caminho para a biblioteca externa libsk-libfido2.so (export SSH_SK_PROVIDER=\/caminho\/para\/libsk-libfido2.so). \u00c9 poss\u00edvel compilar o openssh com suporte embutido \u00e0 biblioteca intermedi\u00e1ria (\u2014with-security-key-builtin), nesse caso, \u00e9 necess\u00e1rio definir o par\u00e2metro \u2018SecurityKeyProvider=internal\u2019.<\/p>\n

Para autentica\u00e7\u00e3o e gera\u00e7\u00e3o de chave, \u00e9 necess\u00e1rio especificar nas configura\u00e7\u00f5es o par\u00e2metro 'SecurityKeyProvider' ou definir a vari\u00e1vel de ambiente SSH_SK_PROVIDER, indicando o caminho para a biblioteca externa libsk-libfido2.so (export SSH_SK_PROVIDER=\/caminho\/para\/libsk-libfido2.so). \u00c9 poss\u00edvel compilar o openssh com suporte embutido para a biblioteca intermedi\u00e1ria (--with-security-key-builtin); nesse caso, o par\u00e2metro 'SecurityKeyProvider=internal' deve ser definido.
\nEm seguida, deve-se executar 'ssh-keygen -t ecdsa-sk' ou, se as chaves j\u00e1 estiverem criadas e configuradas, conectar-se ao servidor usando 'ssh'. Ao executar ssh-keygen, o par de chaves gerado ser\u00e1 salvo em '~\/ .ssh\/ id_ecdsa_sk' e pode ser utilizado como outras chaves. <\/p>\n

A chave p\u00fablica (id_ecdsa_sk.pub) deve ser copiada para o servidor no arquivo authorized_keys. No lado do servidor, apenas a assinatura digital \u00e9 verificada, enquanto a intera\u00e7\u00e3o com os tokens ocorre do lado do cliente (n\u00e3o \u00e9 necess\u00e1rio instalar libsk-libfido2 no servidor, mas o servidor deve suportar o tipo de chaves 'ecdsa-sk'). A chave privada gerada (id_ecdsa_sk) \u00e9 essencialmente um descritor de chave, formando a chave real apenas em combina\u00e7\u00e3o com a sequ\u00eancia secreta armazenada no token U2F. Se a chave id_ecdsa_sk cair nas m\u00e3os de um atacante, para passar pela autentica\u00e7\u00e3o, ele tamb\u00e9m precisar\u00e1 ter acesso ao token de hardware, sem o qual a chave privada armazenada no arquivo id_ecdsa_sk \u00e9 in\u00fatil. <\/p>\n

Al\u00e9m disso, por padr\u00e3o, ao realizar qualquer opera\u00e7\u00e3o com chaves (tanto na gera\u00e7\u00e3o quanto na autentica\u00e7\u00e3o), \u00e9 necess\u00e1ria a confirma\u00e7\u00e3o local da presen\u00e7a f\u00edsica do usu\u00e1rio, por exemplo, \u00e9 solicitado que o usu\u00e1rio toque no sensor do token, o que dificulta ataques remotos em sistemas com o token conectado. Como uma outra camada de prote\u00e7\u00e3o, ao iniciar o ssh-keygen, tamb\u00e9m pode ser solicitado uma senha para acessar o arquivo com a chave. <\/p>\n

Na nova vers\u00e3o do OpenSSH, tamb\u00e9m foi anunciada a upcoming de descontinua\u00e7\u00e3o dos algoritmos que utilizam hashes SHA-1, devido a aumento<\/a><\/noindex> a efic\u00e1cia dos ataques de colis\u00e3o com um prefixo definido (o custo de encontrar uma colis\u00e3o \u00e9 estimado em cerca de 45 mil d\u00f3lares). Uma das pr\u00f3ximas vers\u00f5es planeja desativar por padr\u00e3o a possibilidade de usar o algoritmo de assinatura digital de chave p\u00fablica «ssh-rsa», que \u00e9 mencionado no RFC original para o protocolo SSH e continua amplamente utilizado na pr\u00e1tica (para verificar a aplica\u00e7\u00e3o do ssh-rsa em seus sistemas, voc\u00ea pode tentar se conectar via ssh com a op\u00e7\u00e3o «-oHostKeyAlgorithms=-ssh-rsa»).<\/p>\n

Para suavizar a transi\u00e7\u00e3o para novos algoritmos no OpenSSH, em uma das pr\u00f3ximas vers\u00f5es, ser\u00e1 ativada por padr\u00e3o a configura\u00e7\u00e3o UpdateHostKeys, que permitir\u00e1 transferir automaticamente os clientes para algoritmos mais seguros. Entre os algoritmos recomendados para migra\u00e7\u00e3o est\u00e3o rsa-sha2-256\/512 com base no RFC8332 RSA SHA-2 (suportado desde o OpenSSH 7.2 e utilizado por padr\u00e3o), ssh-ed25519 (suportado desde o OpenSSH 6.5) e ecdsa-sha2-nistp256\/384\/521 com base no RFC5656 ECDSA (suportado desde o OpenSSH 5.7).<\/p>\n

Na vers\u00e3o OpenSSH 8.2, a possibilidade de conex\u00e3o utilizando «ssh-rsa» ainda foi mantida, mas esse algoritmo foi removido da lista CASignatureAlgorithms, que define os algoritmos permitidos para a assinatura digital de novos certificados. Da mesma forma, o algoritmo diffie-hellman-group14-sha1 foi removido dos algoritmos de troca de chaves suportados por padr\u00e3o. Observa-se que o uso do SHA-1 em certificados est\u00e1 associado a um risco adicional, j\u00e1 que um atacante tem tempo ilimitado para encontrar uma colis\u00e3o para um certificado existente, enquanto o tempo de ataque \u00e0s chaves host \u00e9 limitado pelo tempo de conex\u00e3o (LoginGraceTime). <\/p>\n

Ao executar o ssh-keygen, agora o algoritmo rsa-sha2-512 \u00e9 aplicado por padr\u00e3o, que \u00e9 suportado desde o OpenSSH 7.2, o que pode criar problemas de compatibilidade ao tentar processar certificados assinados no OpenSSH 8.2 em sistemas com vers\u00f5es antigas do OpenSSH (para contornar o problema na forma\u00e7\u00e3o da assinatura, \u00e9 poss\u00edvel especificar explicitamente «ssh-keygen -t ssh-rsa» ou usar os algoritmos ecdsa-sha2-nistp256\/384\/521, que s\u00e3o suportados desde o OpenSSH 5.7).<\/p>\n

Outras mudan\u00e7as:<\/p>\n