Após quatro meses de desenvolvimento liberar , uma implementação aberta de cliente e servidor para trabalhar através dos protocolos SSH 2.0 e SFTP.
Uma melhoria importante no lançamento do OpenSSH 8.2 foi a capacidade de usar autenticação de dois fatores usando dispositivos que suportam o protocolo , desenvolvido pela aliança . O U2F permite a criação de tokens de hardware de baixo custo para verificar a presença física do usuário, interagindo com ele via USB, Bluetooth ou NFC. Esses dispositivos são promovidos como meio de autenticação de dois fatores em sites, já são suportados pelos principais navegadores e são produzidos por diversos fabricantes, incluindo Yubico, Feitian, Thetis e Kensington.
Para interagir com dispositivos que confirmam a presença do usuário, novos tipos de chaves “ecdsa-sk” e “ed25519-sk” foram adicionados ao OpenSSH, que utilizam os algoritmos de assinatura digital ECDSA e Ed25519, combinados com o hash SHA-256. Os procedimentos para interagir com tokens são colocados em uma biblioteca intermediária, que é carregada de maneira semelhante à biblioteca para suporte PKCS#11 e é um wrapper no topo da biblioteca , que fornece ferramentas para comunicação com tokens por USB (os protocolos FIDO U2F/CTAP 1 e FIDO 2.0/CTAP 2 são suportados). Biblioteca intermediária libsk-libfido2 preparada por desenvolvedores OpenSSH no núcleo libfido2, bem como para OpenBSD.
Para autenticar e gerar uma chave, você deve especificar o parâmetro “SecurityKeyProvider” nas configurações ou definir a variável de ambiente SSH_SK_PROVIDER, indicando o caminho para a biblioteca externa libsk-libfido2.so (exportar SSH_SK_PROVIDER=/caminho/para/libsk-libfido2. então). É possível construir o openssh com suporte integrado para a biblioteca de camadas (--with-security-key-builtin), neste caso você precisa definir o parâmetro “SecurityKeyProvider=internal”.
Em seguida você precisa executar “ssh-keygen -t ecdsa-sk” ou, se as chaves já tiverem sido criadas e configuradas, conectar-se ao servidor usando “ssh”. Ao executar o ssh-keygen, o par de chaves gerado será salvo em “~/.ssh/id_ecdsa_sk” e poderá ser usado de forma semelhante a outras chaves.
A chave pública (id_ecdsa_sk.pub) deve ser copiada para o servidor no arquivoauthorized_keys. No lado do servidor, apenas a assinatura digital é verificada, e a interação com tokens é realizada no 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 identificador de chave, formando uma chave real apenas em combinação com a sequência secreta armazenada no lado do token U2F. Se a chave id_ecdsa_sk cair nas mãos de um invasor, para passar a autenticação ele também precisará obter acesso ao token de hardware, sem o qual a chave privada armazenada no arquivo id_ecdsa_sk será inútil.
Além disso, por padrão, ao realizar qualquer operação com chaves (tanto durante a geração quanto durante a autenticação), é necessária a confirmação local da presença física do usuário, por exemplo, é proposto tocar no sensor do token, o que dificulta a realizar ataques remotos em sistemas com um token conectado. Como outra linha de defesa, uma senha também pode ser especificada durante a fase de inicialização do ssh-keygen para acessar o arquivo de chave.
A nova versão do OpenSSH também anunciou a descontinuação de algoritmos que usam hashes SHA-1 devido a a eficácia dos ataques de colisão com um determinado prefixo (o custo de seleção de uma colisão é estimado em aproximadamente 45 mil dólares). Em um dos próximos lançamentos, eles planejam desabilitar por padrão a capacidade de usar o algoritmo de assinatura digital de chave pública “ssh-rsa”, que é mencionado na RFC original para o protocolo SSH e continua difundido 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”).
Para facilitar a transição para novos algoritmos no OpenSSH, em uma versão futura a configuração UpdateHostKeys será habilitada por padrão, o que migrará automaticamente os clientes para algoritmos mais confiáveis. 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).
No OpenSSH 8.2, a capacidade de conexão usando “ssh-rsa” ainda está disponível, mas este algoritmo foi removido da lista CASignatureAlgorithms, que define os algoritmos permitidos para assinar digitalmente novos certificados. Da mesma forma, o algoritmo diffie-hellman-group14-sha1 foi removido dos algoritmos de troca de chaves padrão suportados. Observa-se que o uso de SHA-1 em certificados está associado a um risco adicional, uma vez que o invasor tem tempo ilimitado para procurar uma colisão para um certificado existente, enquanto o tempo de ataque às chaves do host é limitado pelo tempo limite de conexão (LoginGraceTime ).
A execução de ssh-keygen agora tem como padrão o algoritmo rsa-sha2-512, que é suportado desde o OpenSSH 7.2, o que pode criar problemas de compatibilidade ao tentar processar certificados assinados no OpenSSH 8.2 em sistemas que executam versões mais antigas do OpenSSH (para contornar o problema quando Quando gerando uma assinatura, você pode especificar explicitamente “ssh-keygen -t ssh-rsa” ou usar os algoritmos ecdsa-sha2-nistp256/384/521, suportados desde OpenSSH 5.7).
Outras mudanças:
- Uma diretiva Include foi adicionada ao sshd_config, que permite incluir o conteúdo de outros arquivos na posição atual do arquivo de configuração (máscaras glob podem ser usadas ao especificar o nome do arquivo);
- A opção “no-touch-required” foi adicionada ao ssh-keygen, o que desativa a necessidade de confirmar fisicamente o acesso ao token ao gerar a chave;
- Uma diretiva PubkeyAuthOptions foi adicionada ao sshd_config, que combina várias opções relacionadas à autenticação de chave pública. Atualmente, apenas o sinalizador "no-touch-required" é compatível para ignorar verificações de presença física para autenticação de token. Por analogia, a opção “no-touch-required” foi adicionada ao arquivoauthorized_keys;
- Adicionada a opção "-O write-attestation=/path" ao ssh-keygen para permitir que certificados de atestado FIDO adicionais sejam gravados ao gerar chaves. O OpenSSH ainda não usa esses certificados, mas eles podem ser usados posteriormente para verificar se a chave está colocada 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 (Comportamento de menor esforço por salto);
- 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 indicando o caminho para a chave como comentário. EM
ssh-keygen e ssh-agent agora também usam rótulos PKCS#11 e o nome do assunto X.509 em vez do caminho da biblioteca como comentários na chave; - Adicionada a capacidade de exportar PEM para chaves DSA e ECDSA para ssh-keygen;
- Adicionado um novo executável, ssh-sk-helper, usado para isolar a biblioteca de acesso ao token FIDO/U2F;
- Adicionada opção de compilação “--with-zlib” ao ssh e sshd para compilação com suporte à biblioteca zlib;
- De acordo com a exigência da RFC4253, um aviso sobre bloqueio de acesso por ultrapassar os limites do MaxStartups é fornecido no banner exibido durante a conexão. Para simplificar o diagnóstico, o cabeçalho do processo sshd, visível ao usar o utilitário ps, agora exibe o número de conexões atualmente autenticadas e o status do limite MaxStartups;
- No ssh e no ssh-agent, ao chamar um programa para exibir um convite na tela, especificado via $SSH_ASKPASS, um sinalizador com o tipo de convite agora é transmitido adicionalmente: “confirm” - caixa de diálogo de confirmação (sim/não), “nenhum ” - mensagem informativa, “em branco” – solicitação de senha;
- Adicionada uma nova operação de assinaturas digitais "find-principals" ao ssh-keygen para pesquisar o arquivo de assinantes permitidos para o usuário associado a uma assinatura digital especificada;
- Suporte aprimorado para isolamento de processos sshd no Linux usando o mecanismo seccomp: desabilitando chamadas de sistema IPC, permitindo clock_gettime64(), clock_nanosleep_time64 e clock_nanosleep().
Fonte: opennet.ru