Et six mois ne se sont pas écoulés: la sortie d'OpenSSH 8.5 est sortie. Détails sur le nouveau produit



Après cinq mois de développement, la version d'OpenSSH 8.5 est publiée, une implémentation ouverte d'un client et d'un serveur pour travailler avec les protocoles SSH 2.0 et SFTP. Les développeurs ont annoncé la traduction à l'avenir d'algorithmes utilisant des hachages SHA-1 dans la catégorie des algorithmes obsolètes. Le problème est que l'efficacité des attaques par collision avec un préfixe donné augmente constamment. Dans le même temps, le coût de sélection d'une collision coûte environ 50 000 $.



Dans un proche avenir, les développeurs promettent de désactiver la possibilité d'utiliser l'algorithme de signature numérique en utilisant la clé publique "ssh-rsa" par défaut. Il est encore répandu aujourd'hui.



Afin de vérifier si cette clé est utilisée dans votre propre système, vous devez essayer de vous connecter via ssh avec l'option "-oHostKeyAlgorithms = -ssh-rsa". Un point important: la désactivation de ce type de signature numérique par défaut n'est pas un rejet complet de l'utilisation des clés RSA. Le problème est que, en plus de SHA-1, le protocole SSH permet d'autres algorithmes pour calculer les hachages. Entre autres possibilités, les développeurs abandonneront l'utilisation des bundles "rsa-sha2-256" (RSA / SHA256) et "rsa-sha2-512" (RSA / SHA512).



Pour simplifier la transition vers de nouveaux algorithmes, la nouvelle version inclut par défaut définition de UpdateHostKeys. C'est elle qui transfère les clients vers de nouveaux algorithmes. La fonction active une extension de protocole spéciale "hostkeys@openssh.com", qui permet au serveur d'informer le client de toutes les clés d'hôte disponibles immédiatement après avoir passé l'authentification. Le client peut refléter ces clés dans le fichier ~ / .ssh / known_hosts, ce qui permet d'organiser la mise à jour des clés d'hôte, facilitant ainsi le changement de clés sur le serveur.



Il convient de noter que l'utilisation de UpdateHostKeys est possible avec un certain nombre de nuances:



  • il doit être mentionné dans UserKnownHostsFile et non utilisé dans GlobalKnownHostsFile;
  • la clé doit être présente sous un seul nom,
  • le certificat de clé d'hôte ne doit pas être utilisé;
  • known_hosts ne doit pas utiliser de masque de nom d'hôte;
  • le paramètre VerifyHostKeyDNS doit être désactivé;
  • le paramètre UserKnownHostsFile doit être actif.


Parmi les algorithmes que les développeurs mentionnent comme recommandés pour la migration:



  • rsa-sha2-256 / 512 basé sur RFC8332 RSA SHA-2 (pris en charge depuis OpenSSH 7.2 et utilisé par défaut);
  • ssh-ed25519 (pris en charge depuis OpenSSH 6.5);
  • ecdsa-sha2-nistp256 / 384/521 basé sur RFC5656 ECDSA (pris en charge depuis OpenSSH 5.7).




Détails des changements dans la nouvelle version



Bien sûr, les développeurs ont ajouté de nombreuses autres fonctionnalités qui couvrent plusieurs catégories.



Sécurité:



  • ssh-agent, . OpenSSH 8.2. ssh-agent . , , . , , , root-.
  • sshd -. PAM (Pluggable Authentication Module). sshd root- Solaris (CVE-2020-14871).


:



  • ssh sshd , . , . , . , . NTRU Prime, , X25519. sntrup4591761x25519-sha512@tinyssh.org sntrup761x25519-sha512@openssh.com ( sntrup4591761 sntrup761).
  • ssh sshd . ECDSA ED25519.
  • TOS/DSCP TCP-.
  • ijndael-cbc@lysator.liu.se, aes256-cbc RFC-4253, .
  • CheckHostIP. , .






  • sshd PerSourceMaxStartups PerSourceNetBlockSize . .
  • ssh sshd LogVerbose, , , .
  • ssh IP-, . .
  • ssh UserKnownHostsFile=none known_hosts .
  • ssh-config KnownHostsCommand, known_hosts .
  • PermitRemoteOpen, RemoteForward SOCKS.
  • ssh FIDO PIN - PIN PIN . , , PIN.
  • contrib/ssh-copy-id.





All Articles