Les connexions SSH sans mot de passe sont-elles plus sécurisées?
J'ai eu une longue discussion avec mes collègues pour savoir si l'authentification SSH basée sur les clés (en particulier pour OpenSSH) est plus sécurisée que l'authentification à l'aide de mots de passe. Mes collègues se connectent toujours à des serveurs avec des mots de passe, tandis que je préfère me connecter à un système sans avoir à entrer un mot de passe à chaque fois.
Ils craignent qu'il ne soit pas sûr de se connecter sans mot de passe. Que dois-je leur dire? Pour moi, les mots de passe sont mauvais car ils peuvent être forcés par la force ou capturés avec un enregistreur de frappe.
Je utilise l ssh-copy-id outil pour copier ma clé publique sur le serveur. Je me connecte ensuite simplement avec ssh servername. En fait, je n'ai qu'à entrer le mot de passe de ma clé privée ne fois à chaque démarrage de mon système. Si mon poste de travail fonctionne pendant 3 jours, je n'ai plus jamais besoin de saisir à nouveau le mot de passe, qui, selon eux, n'est pas sûr. Est-ce vrai? Je sais que les clés sont meilleures, mais je ne sais pas comment leur expliquer cela.
La connexion basée sur une clé est considérée comme beaucoup plus sécurisée que les connexions basées sur un mot de passe dans la perspective d'une tentative de force brute pour accéder à un système tiers: les chances de casser une clé sont effectivement nulles, tandis que les mauvais mots de passe sont trop courants.
Du point de vue d'un système client compromis (votre poste de travail), il n'y aura pas de différence car si les attaquants peuvent obtenir votre clé privée et/ou détourner une session, ils pourraient probablement également installer une sorte d'enregistreur de frappe, ce qui rend la perception avantage des mots de passe inutiles.
C'est aussi sécurisé que votre ordinateur. La clé est assise, non chiffrée, dans la RAM; un attaquant disposant d'un accès physique à votre machine, ou d'un accès root à distance, pourrait l'obtenir.
Pensez-y dans les mêmes termes que si vos collègues utilisaient un programme sécurisé par mot de passe et le laissaient à l'écran avec la base de données disponible sans saisie de mot de passe; si vous verrouillez votre poste de travail lorsque vous vous éloignez et le protégez des activités distantes hostiles, alors il est raisonnablement sécurisé, mais une attaque gelée RAM pourrait toujours théoriquement obtenir la clé.
Mais quelqu'un dans ces positions pourrait facilement installer un enregistreur de frappe, comme vous l'avez souligné. Tant que vous faites attention à la sécurité de votre poste de travail, je n'appellerais pas cela moins sûr que les mots de passe; mais les vrais avantages des connexions basées sur les clés sont vraiment pour la protection contre, par exemple, les attaques par mot de passe par force brute contre le serveur (car les clés sont presque impossibles à forcer par force).
En fait, vos collègues ont raison. Pensez à ce sujet. Vos postes de travail sont fissurés, cela fait quelques jours et maintenant les pirates pwn l'ensemble de votre réseau parce que vous n'utilisez pas un mot de passe ssh.
Cela dit, les mots de passe partagés ne sont jamais bons et constituent une faiblesse majeure du système. Je vais supposer que vous parlez d'accès root.
Ce que je veux dire, c'est qu'ils ont tous les deux des inconvénients et que la sécurité doit être assurée.
Pour tous les serveurs que j'administre, j'utilise une clé SSH de phrase secrète. Cela me donne le meilleur des deux mondes. Un seul mot de passe que je connais, et n'utilisant pas de mot de passe partagé pour les autres utilisateurs.
(et oui, j'ai vu où une clé ssh sans mot de passe a été utilisée pour compromettre l'ensemble du réseau.
Vous êtes aussi sûr que votre maillon le plus faible. Si vos serveurs distants autorisent à la fois l'authentification par mot de passe et l'authentification par clé, vous êtes moins sûr que d'en autoriser un seul.
Vos vulnérabilités supplémentaires pour un système basé sur des clés sur l'authentification par mot de passe (PA) sont:
Un attaquant obtient une copie de votre clé privée protégée par une phrase secrète en disant avoir un accès physique à un disque non chiffré sur n'importe quel système (par exemple, démarrer en mode utilisateur unique), puis exécute une attaque par force brute hors ligne basée sur GPU sur votre clé, puis obtient accès à tous vos systèmes si votre phrase secrète est suffisamment faible (par exemple, 4 mots diceware).
Vous utilisez quelque chose comme ssh-agent qui conserve votre phrase secrète ou votre clé privée en mémoire pour une utilisation ultérieure et un attaquant peut le retirer de votre système d'une manière ou d'une autre (par exemple, un autre utilisateur root était connecté alors que vous aviez le mot de passe en mémoire).
Votre clé était beaucoup moins sécurisée que vous ne le pensiez. Par exemple, la principale faiblesse d'OpenSSH; où le seul caractère aléatoire provenait du identifiant du processus, seules 65536 clés ont été générées. Alors que ces types de problèmes devraient être remarqués et corrigés rapidement, en tant qu'utilisateur final, il est impossible de dire qu'il n'y en a pas faille majeure dans le générateur de nombres aléatoires utilisé pour fabriquer vos clés.
Votre sécurité supplémentaire grâce à l'authentification par clé:
- Les attaques par force brute sont irréalisables pendant la durée de vie de l'univers, sans voler votre clé privée (et si elle était protégée par une phrase secrète, puis briser la phrase secrète).
- Les attaques MITM ne fonctionneront pas (un hôte distant malveillant ne peut pas comprendre votre clé privée/phrase secrète); bien que ssh signale déjà les attaques MITM pour alerter les administrateurs en utilisant les clés d'hôte et
known_hostsdes dossiers.
Dans la pratique, les deux sont tout aussi sûrs. Quiconque peut voler des clés privées ssh de la RAM, peut installer un enregistreur de frappe obtenir vos mots de passe/phrases de passe/clés privées.
Personnellement, j'aime votre solution car une phrase secrète est plus pratique (stockée dans la RAM; sur une machine à un utilisateur qui se verrouille après 5 minutes); bien que je ne mette toujours ma clé privée protégée par mot de passe que sur les machines locales où je suis le seul utilisateur.
Une raison pour laquelle je pense que l'authentification par clé présente un léger avantage en termes de sécurité est qu'il y a des fois où j'ai vu les deux utilisateurs finaux, et même j'ai parfois saisi mon mot de passe dans un champ de nom d'utilisateur plutôt que dans la boîte de dialogue de mot de passe ( en fonction du client ssh). Ou appuyez sur la touche Entrée trop rapidement et le client ssh se ferme, et mon mot de passe est entré dans l'historique de mon terminal.
Si vous ne faites pas attention à chaque fois que vous entrez votre mot de passe, il est possible que votre mot de passe soit ajouté en clair, éventuellement à plusieurs fichiers journaux, potentiellement à l'historique Shell, ou même à une sorte de cheval de Troie. Dans le cas d'une clé sans mot de passe ou d'une clé que vous chargez avec un agent SSH au début de votre session, vous ne devez jamais retaper votre mot de passe, il est donc peu probable que vous saisissiez vos informations d'identification au mauvais endroit et révéliez votre mot de passe à quelqu'un ou à quelque chose que vous ne vouliez pas.
Eh bien, dans un sens, c'est 6. Le premier risque immédiat pour la sécurité d'une connexion par mot de passe serait qu'un utilisateur non autorisé obtienne (par quelque moyen que ce soit) le mot de passe du serveur. De même, une connexion basée sur une clé présente le risque de sécurité qu'un utilisateur non autorisé obtienne l'accès à votre ordinateur. Si vous utilisez un mot de passe complexe sur le serveur, vous courez le risque que les utilisateurs de mot de passe le notent quelque part afin de s'en souvenir. Avec les utilisateurs clés, vous courez le risque qu'ils s'éloignent de leur bureau avec l'ordinateur déverrouillé.
Cela se résume en grande partie au rapport risque/facilité d'utilisation. Bien sûr, vous pouvez exiger des mots de passe sur les clés, n'autoriser que certaines adresses IP par clé et tout autre nombre de mesures de sécurité serrées, mais cela rend vos gens mécontents.
Mais pour répondre à votre question: si nous parlons d'une configuration Vanilla d'OpenSSH, les connexions par mot de passe et par clé ont toutes deux leurs propres points faibles de sécurité différents.
Je désactive toujours la connexion par mot de passe via ssh pour root sur mes systèmes. De cette façon, aucun attaquant ne peut tenter de forcer brutalement le mot de passe.
Vous devez toujours vous méfier de la sécurité sur les systèmes clients. Vous voudrez peut-être faire en sorte que l'agent ssh oublie vos informations d'identification clés lorsque votre écran de verrouillage s'allume. Cela aiderait à empêcher les attaques sur votre ordinateur client de compromettre votre clé.
Quelques réponses décentes ici, mais toutes semblent manquer la marque à mon avis.
L'utilisation d'une paire de clés pour l'authentification remplace le "quelque chose que vous savez" d'un système basé sur un mot de passe par un "quelque chose que vous avez" d'un système de clés ou de jetons. Revenons à cela dans une seconde.
Les clés sont beaucoup plus complexes. Je pense que la plupart des implémentations SSH utilisent par défaut la clé RSA 2048. Comparez cela à un mot de passe à 8 caractères. Même s'ils sont hachés en 256 bits, les mots de passe, car ils n'ont pas le caractère aléatoire des clés, peuvent être forcés brutalement. Schneier a de grandes observations à ce sujet; même les mots de passe soi-disant "bons" ont tendance à n'être qu'une combinaison de données fissurables (un mot avec un nombre et peut-être quelques substitutions simples); nous, les humains, sommes tout simplement trop prévisibles.
Quant à une clé qui n'est aussi sécurisée que le mot de passe pour se connecter, ce n'est pas tout à fait correct. En enveloppant une clé avec un autre mot de passe, vous améliorez considérablement la sécurité car vous utilisez essentiellement l'authentification à deux facteurs; pour accéder à quelque chose que vous avez (la clé), vous devez utiliser quelque chose que vous connaissez (un mot de passe). Oui, l'utilisation de votre mot de passe de connexion pour encapsuler une clé nuirait à cela.
Donc, pour l'affiche originale, je dirais que vous et vos collègues avez tort. Vous l'êtes peut-être moins qu'eux, mais la bonne réponse est que vous devez utiliser à la fois une clé et un mot de passe.