La plupart des guides de configuration d'OpenSSH conseillent de désactiver l'authentification par mot de passe en faveur de l'authentification par clé. Mais à mon avis, l'authentification par mot de passe a un avantage significatif : la possibilité de se connecter d'absolument n'importe où sans clé. Si elle est toujours utilisée avec un mot de passe fort, cela ne devrait pas être un risque pour la sécurité. Mais n'est-ce pas ?
Réponses
Trop de publicités?Vous avez partiellement répondu à votre question : plus l'attaquant peut se connecter à partir d'un grand nombre d'endroits, plus il a de possibilités de pénétrer dans votre serveur par bruteforcing (pensez à DDoS).
Comparez également la longueur de votre mot de passe avec la taille de la clé (généralement des milliers de bits).
Il s'agit d'un compromis, comme le dit @MartinVejmelka.
La raison pour laquelle vous utilisez l'authentification basée sur la clé est que la clé est si loin au-dessus de l'état actuel. ou dans un avenir proche Pour le forçage brutal, vous devez soit venir 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
- Si elle est longue, elle est facilement oubliée
- Il pourrait être surfé sur l'épaule
Une clé est beaucoup plus longue et n'est affichée à aucun moment, ce qui permet d'éviter ces trois problèmes.
De bons points déjà mentionnés ici.
Ce que je considère comme le plus grand risque, étant donné que vous avez pris soin de l'essentiel avec un mot de passe fort, est que beaucoup d'ordinateurs ont des enregistreurs de frappe installés sans que l'utilisateur 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 au meilleur d'entre nous. Un keylogger enverrait par exemple les données de connexion à un pirate qui pourrait alors facilement accéder au serveur.
J'ai récemment été mis en garde par Norton contre le téléchargement de l'installateur de Zombee Mod (pas le jar, l'installateur) pour ajouter un vol au jar de Minecraft. J'ai regardé les détails et Norton a listé beaucoup d'utilitaires sur ce site qui a été marqué comme contenant un cheval de Troie. Je ne sais pas si c'est correct ou non, mais il était assez spécifique avec les noms de fichiers. Il est également connu que les chevaux de Troie sont placés dans (certains) logiciels avant d'être distribués.
L'un des avantages potentiels de SSH par rapport aux mots de passe est que si vous ne spécifiez pas de phrase de passe SSH, vous n'aurez plus jamais à saisir de mot de passe... votre ordinateur est intrinsèquement digne de confiance sur le serveur car il possède la clé. Cela dit, j'utilise généralement toujours une phrase de passe SSH, ce qui exclut cet avantage.
Je trouve que la meilleure réponse à la raison pour laquelle les guides d'utilisation recommandent souvent l'authentification par SSH plutôt que par mot de passe provient du manuel Ubuntu pour SSHOpenSSHKeys. Je cite ,
Si vous ne pensez pas que c'est important, essayez d'enregistrer toutes les tentatives de connexion malveillantes que vous recevez pendant une semaine. Mon ordinateur - un PC de bureau parfaitement ordinaire - a fait l'objet de plus de 4 000 tentatives pour deviner mon mot de passe et de près de 2 500 tentatives d'intrusion rien que la semaine dernière. Combien de milliers de tentatives aléatoires pensez-vous qu'il faudra avant qu'un attaquant ne tombe sur votre mot de passe ?
Essentiellement, si vous avez un mot de passe solide et long, avec de la ponctuation, des majuscules et des minuscules, et des chiffres ... vous serez probablement OK avec l'authentification par mot de passe. De plus, si vous prévoyez de surveiller vos journaux et que vous ne faites pas de choses "super sécurisées" sur le réseau de toute façon ... c'est-à-dire si vous l'utilisez pour un serveur domestique. Dans ce cas, un mot de passe est tout à fait approprié.
La méthode d'authentification par mot de passe n'est vraiment pas sûre (imho). Avec ce mécanisme, le mot de passe sera transmis au serveur sshd (comme @ramon l'a déjà dit). Cela signifie que certains individus pourraient modifier le serveur sshd pour récupérer le mot de passe. Avec une attaque Man-In-The-Middle, ceci 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
y iptables
pour placer 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
.