web-dev-qa-db-fra.com

Quel algorithme de clé d'hôte est préférable d'utiliser pour SSH?

Lorsque vous vous connectez pour la première fois à un serveur SSH qui n'est pas contenu dans votre known_hosts fichier votre client SSH affiche l'empreinte de la clé publique que le serveur a donnée. J'ai trouvé à partir de cette question ici qu'en tant que client, vous pouvez spécifier dans ssh_config laquelle des paires de clés publiques des hôtes '/etc/ssh/ répertoire que vous souhaitez.

Du ssh_config page de manuel J'ai trouvé que les valeurs par défaut actuelles sont les suivantes:

    [email protected],
    [email protected],
    [email protected],
    [email protected],
    [email protected],
    [email protected],
    ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,
    ecdsa-sha2-nistp521,ssh-ed25519,
    ssh-rsa,ssh-dss

Ce n'est que récemment que mon serveur SSH m'a envoyé une empreinte digitale ECDSA au lieu d'un RSA, mais je me demandais quel algorithme devrais-je choisir si cela importait même?

This article affirme que l'ECDSA est the old elliptic-curve DSA implementation that is known to have severe vulnerabilites Dois-je utiliser RSA ou le dernier algorithme ed25519?

encryptionsshrsaasymmetricecc
24
user4191887

Actuellement,

  • Le RSA est toujours recommandé comme étalon-or (solide, large compatible)
  • ed25519 est bon (indépendant du NIST, mais pas compatible avec tous les anciens clients).

Le serveur fournit généralement plus de types de clés d'hôte différents, vous ciblez donc la compatibilité. L'ordre de priorité dans la configuration client est du plus fort au plus compatible.

Franchement, pour vous, en tant qu'utilisateur final, cela ne devrait pas avoir d'importance. Certaines des clés peuvent avoir des problèmes de sécurité, mais aucune d'entre elles n'est considérée comme complètement rompue avec des longueurs raisonnables, ce qui pourrait éventuellement provoquer une attaque de l'homme du milieu ou quelque chose de similaire.

L'article mentionne des "vulnérabilités graves", mais ne dit rien de spécifique. S'il avait une telle vulnérabilité de service, personne ne l'utiliserait, ne la prendrait en charge ni ne la recommanderait. Sans aucune référence, il est assez difficile de commenter vos préoccupations.

14
Jakuje

Étant donné que les algorithmes sont dans un état de flux, je trouve que l'utilisation d'un outil ssh-audit (disponible sur Github) ( voici un fork plus récent) est extrêmement utile.

Un exemple de sortie d'un paramètre SSH actuel mais sécurisé est donné ci-dessous:

# general
(gen) banner: SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3
(gen) software: OpenSSH 6.7p1
(gen) compatibility: OpenSSH 6.5+, Dropbear SSH 2013.62+
(gen) compression: enabled ([email protected])

# key exchange algorithms
(kex) [email protected]          -- [info] available since OpenSSH 6.5, Dropbear SSH 2013.62
(kex) diffie-hellman-group-exchange-sha256  -- [warn] using custom size modulus (possibly weak)
                                            `- [info] available since OpenSSH 4.4

# Host-key algorithms
(key) ssh-ed25519                           -- [info] available since OpenSSH 6.5
(key) ssh-rsa                               -- [info] available since OpenSSH 2.5.0, Dropbear SSH 0.28

# encryption algorithms (ciphers)
(enc) [email protected]         -- [info] available since OpenSSH 6.5
                                            `- [info] default cipher since OpenSSH 6.9.
(enc) [email protected]                -- [info] available since OpenSSH 6.2
(enc) [email protected]                -- [info] available since OpenSSH 6.2
(enc) aes256-ctr                            -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
(enc) aes192-ctr                            -- [info] available since OpenSSH 3.7
(enc) aes128-ctr                            -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52

# message authentication code algorithms
(mac) [email protected]         -- [info] available since OpenSSH 6.2
(mac) [email protected]         -- [info] available since OpenSSH 6.2
(mac) [email protected]              -- [info] available since OpenSSH 6.2
(mac) hmac-sha1                             -- [warn] using encrypt-and-MAC mode
                                            `- [warn] using weak hashing algorithm
                                            `- [info] available since OpenSSH 2.1.0, Dropbear SSH 0.28

# algorithm recommendations (for OpenSSH 6.7)
(rec) -hmac-sha1                            -- mac algorithm to remove

Paramètres utilisés pour /etc/ssh/sshd_config:

KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256
Ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr
# Following MACs does not work on Mac OSX 10.10 or older
MACs [email protected],[email protected],[email protected],hmac-sha1

Paramètres utilisés pour /etc/ssh/ssh_config:

HostKeyAlgorithms [email protected],[email protected],ssh-ed25519,ssh-rsa
KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256
MACs [email protected],[email protected],[email protected],hmac-sha1
Ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr
11
John Greene

CHOISIR UN ALGORITHME ET UNE TAILLE DE CLÉ

SSH prend en charge plusieurs algorithmes de clé publique pour les clés d'authentification. Ceux-ci inclus:

  • rsa - un ancien algorithme basé sur la difficulté de factoriser de grands nombres. Une taille de clé d'au moins 2048 bits est recommandée pour RSA; 4096 bits, c'est mieux. RSA vieillit et des avancées significatives sont en cours dans l'affacturage. Le choix d'un algorithme différent peut être conseillé. Il est fort possible que l'algorithme RSA devienne pratiquement cassable dans un avenir prévisible. Tous les clients SSH prennent en charge cet algorithme.

  • dsa - un ancien algorithme de signature numérique du gouvernement américain. Il est basé sur la difficulté de calculer des logarithmes discrets. Une taille de clé de 1024 serait normalement utilisée avec elle. Le DSA dans sa forme originale n'est plus recommandé.

  • ecdsa - un nouvel algorithme de signature numérique standardisé par le gouvernement américain, utilisant des courbes elliptiques. Il s'agit probablement d'un bon algorithme pour les applications actuelles. Seules trois tailles de clé sont prises en charge: 256, 384 et 521 bits (sic!). Nous vous recommandons de toujours l'utiliser avec 521 bits, car les clés sont toujours petites et probablement plus sécurisées que les clés plus petites (même si elles devraient également être en sécurité). La plupart des clients SSH prennent désormais en charge cet algorithme.

  • ed25519 - c'est un nouvel algorithme ajouté dans OpenSSH. Le support de celui-ci chez les clients n'est pas encore universel. Par conséquent, son utilisation dans des applications à usage général peut ne pas encore être recommandée.

voir https://www.ssh.com/ssh/keygen/#sec-Choosing-an-Algorithm-and-Key-Size

8
cdmo