Após quatro meses de desenvolvimento lançamento , uma implementação aberta de cliente e servidor para trabalhar com os protocolos SSH 2.0 e SFTP.
A principal melhoria na versão OpenSSH 8.2 foi a adição do suporte à autenticação em duas etapas utilizando dispositivos compatíveis com o protocolo , desenvolvido pela aliança . O U2F permite a criação de tokens de hardware de baixo custo para confirmar a presença física do usuário, sendo compatíveis com USB, Bluetooth ou NFC. Esses dispositivos estão sendo promovidos como um meio de autenticação em duas etapas em sites, já são suportados pelos principais navegadores e são fabricados por diversas empresas, incluindo Yubico, Feitian, Thetis e Kensington.
Para a interação com dispositivos que confirmam a presença do usuário, o OpenSSH adicionou novos tipos de chave ‘ecdsa-sk’ e ‘ed25519-sk’, que utilizam algoritmos de assinatura digital ECDSA e Ed25519, combinados com o hash SHA-256. Os procedimentos de interação com os tokens foram movidos para uma biblioteca intermediária, que é carregada de forma semelhante à biblioteca para suporte a PKCS#11 e atua como uma camada sobre a biblioteca , fornecendo recursos para comunicação com tokens através do USB (suportando os protocolos FIDO U2F/CTAP 1 e FIDO 2.0/CTAP 2). A biblioteca intermediária libsk-libfido2, desenvolvida pelos criadores do OpenSSH, é integrada ao conjunto principal da libfido2, assim como o driver HID Para autenticação e geração de chaves, é necessário especificar na configuração o parâmetro ‘SecurityKeyProvider’ ou definir a variável de ambiente SSH_SK_PROVIDER, indicando o caminho para a biblioteca externa libsk-libfido2.so (export SSH_SK_PROVIDER=/caminho/para/libsk-libfido2.so). É possível compilar o openssh com suporte embutido à biblioteca intermediária (—with-security-key-builtin), nesse caso, é necessário definir o parâmetro ‘SecurityKeyProvider=internal’.
Em seguida, você deve executar ‘ssh-keygen -t ecdsa-sk’ ou, se as chaves já foram criadas e configuradas, conectar-se ao servidor utilizando ‘ssh’. Ao executar ‘ssh-keygen’, o par de chaves criado será salvo em ‘~/.ssh/id_ecdsa_sk’ e pode ser usado da mesma forma que outras chaves.
Далее нужно запустить «ssh-keygen -t ecdsa-sk» или, если ключи уже созданы и настроены, подключиться к серверу при помощи «ssh». При запуске ssh-keygen созданная пара ключей будет сохранена в «~/.ssh/id_ecdsa_sk» и может использоваться аналогично другим ключам.
A chave pública (id_ecdsa_sk.pub) deve ser copiada para o servidor no arquivo authorized_keys. Do lado do servidor, apenas a assinatura digital é verificada, enquanto a interação com os tokens ocorre do lado do cliente (não é necessário instalar libsk-libfido2 no servidor, mas o servidor deve suportar o tipo de chave «ecdsa-sk»). A chave privada gerada (id_ecdsa_sk) é essencialmente um descritor da chave, formando a chave real apenas em combinação com a sequência secreta armazenada no token U2F. Se a chave id_ecdsa_sk cair nas mãos de um atacante, para passar pela autenticação, ele também precisará ter acesso ao token de hardware, sem o qual a chave privada armazenada no arquivo id_ecdsa_sk é inútil.
Além disso, por padrão, ao realizar qualquer operação com chaves (tanto na geração quanto na autenticação), é necessária a confirmação local da presença física do usuário, por exemplo, é solicitado que o usuário toque no sensor do token, o que dificulta ataques remotos em sistemas com o token conectado. Como uma outra camada de proteção, ao iniciar o ssh-keygen, também pode ser solicitado uma senha para acessar o arquivo com a chave.
Na nova versão do OpenSSH, também foi anunciada a upcoming de descontinuação dos algoritmos que utilizam hashes SHA-1, devido a da eficiência de ataques de colisão com um prefixo determinado (o custo para encontrar uma colisão é estimado em cerca de 45 mil dólares). Em uma das próximas versões, planeja-se desabilitar por padrão a possibilidade de usar o algoritmo de assinatura digital com chave pública «ssh-rsa», que é mencionado no RFC original para o protocolo SSH e continua amplamente difundido na prática (para verificar a aplicação do ssh-rsa em seus sistemas, você pode tentar se conectar via ssh com a opção «-oHostKeyAlgorithms=-ssh-rsa»).
Para suavizar a transição para novos algoritmos no OpenSSH, em uma das próximas versões, será ativada por padrão a configuração UpdateHostKeys, que permitirá transferir automaticamente os clientes para algoritmos mais seguros. Entre os algoritmos recomendados para migração estão rsa-sha2-256/512 com base no RFC8332 RSA SHA-2 (suportado desde o OpenSSH 7.2 e utilizado por padrão), 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).
Na versão OpenSSH 8.2, a possibilidade de conexão usando "ssh-rsa" ainda está disponível, 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ão. Observa-se que o uso do SHA-1 em certificados apresenta um risco adicional, pois um atacante tem tempo ilimitado para buscar colisões em um certificado existente, enquanto o tempo de ataque nas chaves do host é limitado pelo tempo limite de conexão (LoginGraceTime).
Ao executar ssh-keygen, agora o algoritmo rsa-sha2-512 é aplicado por padrão, que é suportado a partir do OpenSSH 7.2, o que pode criar problemas de compatibilidade ao tentar processar certificados assinados no OpenSSH 8.2 em sistemas com versões antigas do OpenSSH (para contornar o problema ao gerar a assinatura, pode-se especificar explicitamente "ssh-keygen -t ssh-rsa" ou usar os algoritmos ecdsa-sha2-nistp256/384/521, que são suportados a partir do OpenSSH 5.7).
Outras mudanças:
- No sshd_config, foi adicionada a diretiva Include, que permite incluir o conteúdo de outros arquivos na posição atual do arquivo de configuração (é possível usar máscaras glob para o nome do arquivo);
- No ssh-keygen, foi adicionada a opção "no-touch-required", que desabilita a necessidade de confirmação física para acessar o token ao gerar a chave;
- No sshd_config, foi adicionada a diretiva PubkeyAuthOptions, que combina diferentes opções relacionadas à autenticação por chave pública. No momento, apenas a flag "no-touch-required" é suportada para pular a verificação de presença física durante a autenticação usando um token. De forma análoga, a opção "no-touch-required" foi adicionada ao arquivo authorized_keys;
- No ssh-keygen, foi adicionada a opção "-O write-attestation=/path", permitindo gravar certificados de atestação FIDO adicionais ao gerar chaves. O OpenSSH ainda não utiliza esses certificados, mas eles podem ser usados posteriormente para verificar a localização da chave em um armazenamento de hardware confiável;
- Nas configurações de ssh e sshd, é agora possível definir o modo de priorização de tráfego através da diretiva IPQoS. (Lower-Effort Per-Hop Behavior);
- No ssh ao definir o valor "AddKeysToAgent=yes", se a chave não contiver um campo de comentário, ela será adicionada ao ssh-agent com o caminho da chave como comentário.
No ssh-keygen e ssh-agent, agora também são utilizadas as etiquetas PKCS#11 e o nome do sujeito X.509 como comentários na chave em vez do caminho para a biblioteca. - No ssh-keygen, foi adicionada a capacidade de exportar PEM para chaves DSA e ECDSA.
- Foi adicionado um novo arquivo executável ssh-sk-helper, utilizado para isolar a biblioteca de acesso a tokens FIDO/U2F.
- No ssh e sshd, foi adicionada a opção de compilação "--with-zlib" para suporte à biblioteca zlib.
- De acordo com a RFC4253, o banner exibido ao se conectar agora mostra um aviso sobre o bloqueio de acesso devido ao excesso dos limites de MaxStartups. Para facilitar o diagnóstico, o cabeçalho do processo sshd, visível ao usar a ferramenta ps, agora exibe o número de conexões autenticadas no momento e o estado do limite MaxStartups.
- No ssh e ssh-agent, ao chamar o programa para exibir o prompt, definido por meio de $SSH_ASKPASS, agora é passado adicionalmente um sinalizador com o tipo de prompt: "confirm" — diálogo de confirmação (sim/não), "none" — mensagem informativa, "blank" — solicitação de senha.
- No ssh-keygen, foi adicionada uma nova operação de assinatura digital "find-principals" para buscar no arquivo allowed-signers do usuário ligado à assinatura digital especificada.
- Melhor suporte para isolamento do processo sshd no Linux através do mecanismo seccomp: chamadas de sistema IPC foram proibidas, enquanto clock_gettime64(), clock_nanosleep_time64 e clock_nanosleep() foram permitidos.
Fonte: opennet.ru
