Est-il préférable d'utiliser une clé publique pour se connecter à SSH que d'enregistrer un mot de passe?
L'utilisation d'une paire de clés publique/privée est assez pratique pour se connecter à des hôtes fréquentés, mais si j'utilise une paire de clés sans mot de passe, est-ce plus sûr (ou moins sûr) qu'un mot de passe? La sécurité autour de mon fichier de clé privée est primordiale, mais disons que mon fichier de clé privée magique n'était qu'une liste de mots de passe vers divers hôtes, y a-t-il une différence?
Ma réponse est que l'utilisation de paires de clés publiques est beaucoup chose plus sage à faire que l'utilisation de mots de passe ou de listes de mots de passe. Je me concentrerai sur des choses peu connues sur les différentes formes d'authentification SSH, et je ne vois aucune autre réponse les mentionnant.
Tout d'abord, vous devez comprendre que l'authentification des utilisateurs est un processus différent et distinct de la mise en place du canal sécurisé . En termes simples, cela signifie que d'abord, la clé publique du serveur est utilisée (si elle est acceptée!) Pour construire le canal SSH sécurisé, en permettant la négociation d'une clé symétrique qui sera utilisée pour protéger la session restante, activer le canal confidentialité, protection de l'intégrité et authentification du serveur.
Après le canal est fonctionnel et sécurisé, l'authentification de l'utilisateur a lieu. Les deux façons habituelles de le faire sont d'utiliser un mot de passe ou une paire de clés publiques. L'authentification par mot de passe fonctionne comme vous pouvez l'imaginer: le client envoie son mot de passe sur le canal sécurisé, le serveur vérifie qu'il s'agit bien du mot de passe de l'utilisateur spécifique et autorise l'accès. Dans le cas de la clé publique, nous avons une situation très différente. Dans ce cas, le serveur a la clé publique de l'utilisateur stockée. Ce qui se passe ensuite, c'est que le serveur crée une valeur aléatoire (nonce), la crypte avec la clé publique et l'envoie à l'utilisateur. Si l'utilisateur est censé être, il peut décrypter le défi et le renvoyer au serveur, qui confirme ensuite l'identité de l'utilisateur. C'est le classique modèle défi-réponse. (Dans SSHv2, quelque chose d'un peu différent mais conceptuellement proche est en fait utilisé)
Comme vous pouvez l'imaginer, dans le premier cas, le mot de passe est réellement envoyé au serveur (à moins que SSH n'utilise une réponse de défi de mot de passe), dans le second, votre clé privée ne quitte jamais le client. Dans le scénario imaginaire où quelqu'un intercepte le trafic SSL et est capable de le décrypter (en utilisant une clé privée de serveur compromise, ou si vous acceptez une mauvaise clé publique lors de la connexion au serveur) ou a accès au serveur ou au client, votre mot de passe sera connu - avec l'authentification par clé publique-privée et le modèle de réponse au défi, vos informations privées ne tomberont jamais entre les mains de l'attaquant. Ainsi, même si un serveur auquel vous vous connectez est compromis, les autres serveurs pour lesquels vous utilisez la même clé ne le seraient pas!
Il y a d'autres avantages à utiliser une paire de clés publiques: la clé privée ne doit pas être stockée en texte clair dans votre PC client comme vous le suggérez. Bien sûr, cela laisse le fichier de clé privée ouvert à tout compromis comme le ferait un fichier de mot de passe non chiffré, mais il est plus facile de déchiffrer (à la connexion) et d'utiliser la clé privée. Il doit être stocké chiffré, et vous devez fournir une phrase de passe généralement longue pour le déchiffrer chaque fois qu'il est utilisé.
Bien sûr, cela signifie que vous devrez fournir la longue phrase secrète chaque fois que vous vous connectez à un serveur, pour déverrouiller votre clé privée - Il existe des moyens de contourner cela. Vous pouvez augmenter l'utilisabilité du système en utilisant un agent d'authentification: il s'agit d'un logiciel qui déverrouille vos clés pour la session en cours, lorsque vous vous connectez à gnome par exemple ou lorsque vous connectez ssh pour la première fois à votre client, vous pouvez donc simplement tapez 'ssh remote-system-ip' et connectez-vous, sans fournir de phrase secrète, et répétez l'opération jusqu'à ce que vous vous déconnectiez de votre session.
Donc, pour résumer, l'utilisation de paires de clés publiques offre beaucoup plus de protection que l'utilisation de mots de passe ou de listes de mots de passe qui peuvent être capturés si client, serveur = ou la session sécurisée est compromise. Dans le cas où vous n'utilisez pas de phrase secrète (ce qui ne devrait pas se produire), les paires de clés publiques offrent toujours une protection contre les sessions et les serveurs compromis.
Par rapport à une liste stockée de mots de passe (longs et aléatoires), une clé privée SSH stockée offre la même sécurité: les choses sont sûres tant que votre fichier privé reste privé.
La clé privée, cependant, est beaucoup plus pratique, les deux pratiquement (en ce moment, les clients SSH la prennent en charge immédiatement, contrairement à un fichier de mots de passe personnalisé que vous devez utiliser avec certains copier-coller manuel) et théoriquement (vous pouvez réutiliser la même clé pour chaque hôte auquel vous souhaitez vous connecter, tandis qu'une liste de mots de passe augmentera linéairement avec le nombre d'hôtes contactés, sauf si vous réutilisez le même mot de passe pour plusieurs hôtes, ce qui est - mauvais).
Cela dépend des menaces que vous envisagez.
Le principal point de l'authentification par clé publique/privée n'est pas de divulguer votre secret, même à la partie à laquelle vous vous authentifiez. Pour cette raison, il est préférable d'utiliser des clés, car vous n'envoyez jamais votre site secret à votre machine.
Cependant, si la menace que vous considérez est locale et si vous ne protégez pas vos clés privées avec un mot de passe, le stockage d'une liste de mots de passe en clair revient à peu près au même stockage des clés privées sans protection.
Pour cette raison, il est utile de protéger vos clés privées avec un mot de passe et d'utiliser des outils tels que ssh-agent (pour plus de commodité). Sur OSX, cela peut également être intégré à KeyChain, de sorte que vous n'aurez peut-être même pas besoin de déverrouiller la clé privée (au niveau de l'application, uniquement au niveau du démon de sécurité) pour pouvoir l'utiliser via SSH (essentiellement, le KeyChain et le démon de sécurité s'occupe de ssh-agent).
La principale différence entre l'utilisation d'une clé privée sans mot de passe et l'utilisation de mot de passe en texte brut pour l'autorisation SSH est autorisation par quelque chose que vous avez (votre clé privée) ou par quelque chose que vous savez (votre mot de passe mémorisé). Ils sont de race différente, mais il est difficile de dire que l'un est finalement meilleur ou plus sûr.
Autoriser par quelque chose que vous avez est normalement plus difficile pour l'attaquant de se répliquer à l'improviste - il est plus facile de forcer/deviner votre mot de passe plus simple que de répliquer votre clé. Mais il a un inconvénient majeur - maintenant garder votre clé privée vraiment secrète devient primordial. Si vous utilisez quelque chose que vous seul connaissez (mot de passe mémorisé), il devrait être plus facile de le conserver de cette façon (au moins théoriquement). Mais si vous devez le mémoriser, vous utilisez probablement quelque chose de pas si complexe.
C'est donc à vous de décider ce qui est le plus probable - votre clé privée forte étant volée ou un mot de passe moins fort deviné (ou acquis d'une autre manière).
Il y a une exception ici - si vous voulez dire dans votre question que vous stockerez des mots de passe très longs, complexes et aléatoires dans votre fichier secret au lieu d'utiliser une clé privée, alors il y a probablement peu de différence entre les deux encore une différence (j'ai raté la partie, voir la réponse de @ john pour un bel article à ce sujet). Dans ce cas, les deux sont quelque chose que vous avez , gardez-le secret types, mais alors demandez-vous - pourquoi le faire en premier lieu si c'est pour cela que les clés privées ont été conçues? vous devez rester avec des clés privées dans ce cas.
Le document référencé discute des mots de passe saisis dans une session ssh; Je pense que cela et les commentaires de Richard valent la peine d'être conservés, mais ne croyez plus en la réponse elle-même. (Je préfère toujours les clés publiques.)
Song, Wagner et Tian ont montré qu'il est possible d'accélérer les recherches de mot de passe par force brute environ 50 fois en utilisant les informations de synchronisation de ssh sessions . Noack a revu son étude et a trouvé que SSH2 était également vulnérable à l'analyse de synchronisation.
L'attaque fait deux hypothèses:
Le hachage de mot de passe est disponible pour le craquage par force brute.Un attaquant peut obtenir des horodatages précis sur les paquets envoyés entre les hôtes, ou autrement acquérir des informations de synchronisation.
Les clés publiques sont non seulement plus pratiques, mais plus sécurisées contre certaines menaces.
Si vous utilisez des clés "logicielles" (c'est-à-dire des clés stockées dans votre répertoire .ssh ou équivalent), vous êtes essentiellement au même niveau que le stockage de mots de passe.
OpenSSH a maintenant un support PKCS # 11 presque décent, le même est disponible dans KiTTY (un fork PuTTY) donc pour vraiment utiliser l'authentification par clé publique, optez pour une carte à puce. Ensuite, il y a une réelle différence avec les mots de passe. Un fichier de clé logiciel, protégé par un mot de passe, peut être répliqué de la même manière qu'un mot de passe standard, contrairement à une carte à puce.