web-dev-qa-db-fra.com

Quelles sont les différences entre les clés RSA, DSA et ECDSA utilisées par ssh?

Dans mon /etc/ssh/ répertoire, je peux voir trois que j'ai trois types différents de clés ssh:

-rw------- 1 root root    607 Oct  4 22:43 ssh_Host_dsa_key
-rw-r--r-- 1 root root    623 Oct  4 22:43 ssh_Host_dsa_key.pub
-rw------- 1 root root    241 Oct  4 22:43 ssh_Host_ecdsa_key
-rw-r--r-- 1 root root    194 Oct  4 22:43 ssh_Host_ecdsa_key.pub
-rw------- 1 root root   1602 Oct  4 22:43 ssh_Host_rsa_key
-rw-r--r-- 1 root root    378 Oct  4 22:43 ssh_Host_rsa_key.pub

Quelles sont les différences entre les clés RSA, DSA et ECDSA de ssh, et ai-je besoin des trois?

Veuillez expliquer la différence entre eux et comment les utiliser.

encryptionauthenticationsshrsadsa
11
Chaminda Bandara

À quoi servent ces fichiers?

Ce sont vos clés d'hôte qui identifient de manière unique votre hôte. Lorsque OpenSSH est démarré pour la première fois, il générera ces paires de clés. Lorsqu'un client SSH se connecte à votre serveur, il annonce qu'il souhaite authentifier l'hôte à l'aide d'un algorithme particulier. Comme plusieurs sont pris en charge, OpenSSH génère simplement un de chaque type. Cela permet à votre serveur d'être identifié avec plusieurs types d'empreintes digitales.

Tiré de la page de manuel d'OpenSSH, ssh(1) :

When connecting to a server for the first time, a fingerprint of the server's
public key is presented to the user (unless the option StrictHostKeyChecking
has been disabled). Fingerprints can be determined using ssh-keygen(1):

    $ ssh-keygen -l -f /etc/ssh/ssh_Host_rsa_key

If the fingerprint is already known, it can be matched and the key can be
accepted or rejected. If only legacy (MD5) fingerprints for the server are
available, the ssh-keygen(1) -E option may be used to downgrade the fingerprint
algorithm to match.

Les fichiers se terminant par .pub ne sont pas sensibles. Ils sont transmis à tout client qui tente une connexion. Les fichiers sans cette extension sont les clés privées. Si ceux-ci sont divulgués, n'importe qui pourra usurper l'identité de votre serveur SSH avec n'importe quel client. Les clés privées sont utilisées pour prouver au client que les clés publiques transmises sont en fait la propriété du serveur.

Lors de la connexion à un serveur SSH, une série d'événements a lieu:

  • Le client SSH se connecte au serveur et annonce son algorithme préféré.
  • Le serveur envoie la clé publique souhaitée au client, si elle est prise en charge.
  • Le client calcule l'empreinte digitale de la clé publique.
  • Pour la première connexion, l'empreinte digitale est enregistrée dans known_hosts.
  • Pour les connexions suivantes, l'empreinte digitale est comparée à celle enregistrée.

Lors de la première connexion, l'empreinte digitale est affichée à l'utilisateur et l'utilisateur est invité à accepter l'empreinte digitale. Ceci est connu comme [~ # ~] tofu [~ # ~], ou Trust-On-First-Use. Lors des connexions suivantes, l'empreinte digitale est vérifiée en silence et automatiquement. En cas de non-concordance, le client SSH refusera de se connecter et avertira l'utilisateur qu'une attaque MITM peut se produire. Ce comportement garantit que toutes les connexions futures sont authentiques tant que la première connexion est authentique. Une attaque MITM, ou le serveur SSH changeant ses clés d'hôte pour une raison quelconque, invalidera cela et nécessitera une nouvelle authentification.

De quels fichiers avez-vous besoin?

Vous n'avez pas besoin tous les trois et vous pouvez supprimer l'un d'eux, mais un client SSH ne pourra vérifier l'empreinte de votre serveur que si une empreinte prise en charge est stockée dans le known_hosts fichier. Au minimum, les clés RSA doivent être conservées. Tous les clients ne prennent pas en charge ECDSA et (EC) DSA a des problèmes de sécurité et n'est généralement plus recommandé. Il n'y a cependant aucun inconvénient à les garder tous. Un bref résumé des algorithmes couramment disponibles du point de vue de la sécurité:

  • [~ # ~] rsa [~ # ~] est bien considéré et pris en charge partout. Il est considéré comme assez sûr. Les tailles de clé courantes vont jusqu'à 4096 bits et aussi bas que 1024. La taille de clé est réglable. Vous devez choisir RSA .
  • [~ # ~] dsa [~ # ~] n'est plus couramment utilisé, car mauvais caractère aléatoire when génération d'une signature peut faire fuir la clé privée. Dans le passé, il était garanti de fonctionner partout selon RFC 4251 , mais ce n'est plus le cas. DSA a été standardisé comme étant seulement 1024 bits (en FIPS 186-2, bien que FIPS 186-3 a augmenté cette limite). OpenSSH 7.0 et plus récent en fait désactiver cet algorithme.
  • [~ # ~] ecdsa [~ # ~] est plus récent et est basé sur DSA. Il a les mêmes faiblesses que DSA, mais il est généralement considéré comme plus sûr, même avec des tailles de clé plus petites. Il utilise les courbes NIST (P256).
  • Ed25519 , bien qu'il ne soit pas répertorié, est disponible sur les nouvelles installations OpenSSH. Il est similaire à l'ECDSA mais utilise un courbe supérieure , et il n'a pas les mêmes faiblesses lorsque des RNG faibles sont utilisés comme DSA/ECDSA. Il est généralement considéré comme le plus fort mathématiquement.
16
forest