Pourquoi l'authentification par mot de passe SSH constitue-t-elle un risque pour la sécurité?
La plupart des guides de configuration d'OpenSSH recommandent de désactiver l'authentification par mot de passe au profit de l'authentification par clé. Mais à mon avis, l'authentification par mot de passe a un avantage significatif: la possibilité de se connecter de n'importe où sans clé. S'il est toujours utilisé avec un mot de passe fort, cela ne devrait pas constituer un risque pour la sécurité. Ou devrait-il?
Il existe des avantages et des inconvénients pour l'authentification pw ou basée sur les clés.
Dans certains cas, par exemple, l'authentification par clé est moins sécurisée que l'authentification par mot de passe. Dans d'autres cas, sa base pw est moins sécurisée. Dans certains cas, l'un est plus pratique, dans d'autres, moins.
Tout se résume à ceci: lorsque vous effectuez une authentification par clé, vous devez sécuriser votre clé avec une phrase de passe. À moins que ssh-agent ne soit en cours d'exécution (ssh-agent vous libère de la saisie de votre phrase secrète à chaque fois), vous n'avez rien gagné en termes de commodité. La sécurité est contestable: le vecteur d'attaque est maintenant passé du serveur à VOUS, ou à votre compte, ou à votre machine personnelle, (...) - ceux-ci peuvent ou non être plus faciles à casser.
Sortez des sentiers battus lorsque vous décidez de cela. Que vous gagniez ou perdiez en termes de sécurité dépend du reste de votre environnement et d'autres mesures.
edit: Oh, je viens de voir que vous parlez d'un serveur domestique. J'étais dans la même situation, "mot de passe" ou "clé USB avec clé dessus" toujours avec moi? Je suis allé pour l'ancien mais a changé le port d'écoute SSH en quelque chose de différent de 22. Cela empêche tous ces kiddies de script boiteux de forcer des plages de réseau entières.
L'utilisation des clés ssh a une caractéristique unique par rapport à la connexion par mot de passe: vous pouvez spécifier les commandes autorisées. Cela peut être fait en modifiant ~/.ssh/authorized_keys fichier sur le serveur.
Par exemple,
command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...
permettrait uniquement la commande `/usr/local/bin/your_backup_script.sh" avec cette clé particulière.
Vous pouvez également spécifier les hôtes autorisés pour la clé:
from="yourclient,yourotherclient", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...
Ou combinez les deux:
from="yourbackupserver", command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...
Avec les clés, vous pouvez également accorder un accès temporaire à un utilisateur (par exemple, un consultant) à un serveur sans révéler le mot de passe de ce compte particulier. Une fois que le consultant a terminé son travail, la clé temporaire peut être retirée.
Vous pouvez tirer le meilleur parti des deux mondes en autorisant uniquement l'authentification par mot de passe à partir de votre réseau. Ajoutez ce qui suit à la fin de votre sshd_config:
PasswordAuthentication no
Match Address 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
PasswordAuthentication yes
Vous avez partiellement répondu à votre question - plus l'attaquant peut se connecter, plus il a de possibilités de pénétrer votre serveur par bruteforcing (pensez aux DDoS).
Comparez également la longueur de votre mot de passe avec la taille de la clé (généralement des milliers de bits).
Lorsque vous vous connectez avec un mot de passe, vous transmettez votre mot de passe au serveur. Cela signifie que l'opérateur du serveur peut modifier le SSHD pour accéder à votre mot de passe. Avec l'authentification par clé publique, ils ne peuvent pas obtenir votre clé privée car seule votre clé publique va au serveur.
les touches ssh empêchent l'homme au milieu d'attaquer votre mot de passe.
lorsque vous essayez de vous connecter avec une clé, le serveur crée un défi basé sur votre clé publique et l'envoie à votre client. qui le décryptera et construira une réponse appropriée à envoyer.
Votre clé privée n'est jamais envoyée au serveur et toute personne qui écoute ne peut rien faire sauf intercepter cette seule session.
avec un mot de passe, ils auraient vos informations d'identification.
Ma solution est d'avoir une clé ssh portable dans des formats appropriés sur une partition cryptée sur une clé usb. cela me permet de:
retirez facilement cette clé en cas de perte.
restreindre les serveurs auxquels il me permet d'accéder
et toujours le transporter
bien que l'installation du logiciel de montage soit pénible (truecrypt)
C'est un compromis, comme le dit @MartinVejmelka.
La raison pour laquelle vous utilisez l'authentification basée sur la clé est que la clé est tellement au-dessus du courant ou proche forçage brut que vous devez soit provenir de votre propre PC, soit avoir la clé sur une clé USB ou similaire .
Un mot de passe présente les problèmes suivants:
- S'il est court, il peut être forcé brutalement
- S'il est long, il est facilement oublié
- Il pourrait être surfé à l'épaule
Une clé représente des ordres de grandeur plus longs et n'est affichée à aucun moment, ce qui évite ces trois problèmes.
Un avantage potentiel de SSH sur les mots de passe est que si vous ne spécifiez pas de phrase secrète SSH, vous n'aurez plus jamais à taper un mot de passe ... votre ordinateur est intrinsèquement approuvé sur le serveur car il possède la clé. Cela dit, j'utilise généralement toujours une phrase de passe SSH, donc j'exclus les avantages.
Je trouve que la meilleure réponse aux raisons pour lesquelles les guides de l'utilisateur recommandent souvent SSH plutôt que l'authentification par mot de passe provient du manuel Ubuntu pour SSHOpenSSHKeys. Je cite,
Si vous ne pensez pas que ce soit important, essayez de consigner toutes les tentatives de connexion malveillantes que vous obtiendrez la semaine prochaine. Mon ordinateur - un PC de bureau parfaitement ordinaire - a eu plus de 4 000 tentatives pour deviner mon mot de passe et près de 2 500 tentatives d'effraction au cours de la dernière semaine seulement. Combien de milliers de suppositions aléatoires pensez-vous qu'il faudra avant qu'un attaquant tombe sur votre mot de passe?
Essentiellement, si vous avez un mot de passe très solide avec de la ponctuation, des majuscules et des minuscules et des chiffres ... vous serez probablement d'accord avec l'authentification par mot de passe. De plus, si vous prévoyez de surveiller vos journaux et que vous ne faites pas de toute façon des choses "super sécurisées" sur le réseau ... c'est-à-dire que vous les utilisez pour un serveur domestique. Alors par tous les moyens, un mot de passe fonctionne bien.
Bons points déjà mentionnés ici.
Ce que je considère comme le plus grand risque, étant donné que vous avez pris soin des bases avec un mot de passe fort, c'est que de nombreux ordinateurs ont des enregistreurs de frappe installés sans que l'utilisateur ne s'en rende compte. Il y a même des gens qui créent des sites entiers d'utilitaires utiles qui contiennent des chevaux de Troie, donc cela peut arriver aux meilleurs d'entre nous. Un enregistreur de frappe enverrait par exemple les informations de connexion par e-mail à un pirate informatique qui pourrait alors facilement accéder au serveur.
J'ai récemment été averti par Norton du téléchargement du programme d'installation de Zombee Mod (pas du pot, du programme d'installation) pour ajouter un vol au pot Minecraft. J'ai regardé les détails et Norton a répertorié de nombreux utilitaires sur ce site qui étaient marqués comme contenant un cheval de Troie. Je ne sais pas si c'est correct ou pas, mais c'était assez spécifique avec les noms de fichiers. C'est également un fait connu que les chevaux de Troie sont mis en (certains) warez avant d'être distribués.
La méthode d'authentification Passwd n'est vraiment pas sécurisée (à mon humble avis). Avec ce mécanisme, le mot de passe sera transmis au serveur sshd (comme @ramon l'a déjà dit). Cela signifie que certaines personnes pourraient modifier le serveur sshd pour récupérer le mot de passe. Avec une attaque Man-In-The-Middle, cela est très facile à réaliser à l'intérieur d'un réseau local.
Vous pouvez simplement patcher le serveur sshd en installant ce patch ( https://github.com/jtesta/ssh-mitm ). Utilisez arpspoof et iptables pour mettre votre serveur corrigé entre le client et le serveur sshd authentique.
Veuillez désactiver l'authentification par mot de passe: ouvrez le fichier de configuration /etc/ssh/ssh_config et ajoutez la ligne PasswordAuthentication no.