Pourquoi l'authentification par clé SSH est-elle meilleure que l'authentification par mot de passe?


45

Ce n’est pas tant une question technique que conceptuelle. Je comprends que la cryptographie utilisée dans une clé SSH est beaucoup plus puissante qu'un mot de passe habituel, mais je ne comprends pas pourquoi il est considéré comme plus sécurisé.

La plupart des tutoriels que j'ai lus suggèrent d'utiliser l'authentification par clé SSH plutôt que par mot de passe. Mais je crois comprendre que toute personne ayant accès à un ordinateur client pré-approuvé pourra alors se connecter au serveur, ce qui signifie que le niveau de sécurité fourni par la clé SSH est aussi fort que le niveau de sécurité du serveur physique. machine cliente.

Par exemple, si je configure une clé SSH sur mon téléphone pour se connecter à mon ordinateur personnel, si je perds mon téléphone et que quelqu'un parvient à le déverrouiller, il pourra se connecter à mon ordinateur personnel. Je sais que je peux ensuite retirer la clé de mon téléphone de mon ordinateur personnel, mais je suis vulnérable tant que je ne réalise pas que le périphérique client a été perdu / endommagé.

Ai-je mal compris quelque chose ou ces préoccupations sont-elles valables?


10
Faites les deux - une clé qui nécessite un mot de passe. De cette façon, vous avez besoin d'identifier deux choses, pas une seule. Vous pouvez également invalider des clés perdues assez facilement et avoir plusieurs clés autorisées pour plus de contrôle, etc.
Phoshi

2
Cela devrait probablement être déplacé à la sécurité.

10
@DKGasser: Non, ça ne devrait pas. C'est une question parfaitement valable ici. Ce n’est pas parce que quelque chose peut être déplacé sur un autre site SE que cela devrait être .
Wuffers

4
@DKGasser: Cela pourrait aller sur ce site, c'est une question parfaitement valable là-bas. Mais c’est aussi une question valable ici, alors il n’ya aucune raison de la migrer. Si cette question devait être traitée hors sujet ici, alors oui, elle pourrait être migrée là-bas. Mais il est totalement sur le sujet sur ce site et ne devrait donc pas être migré.
Wuffers

3
ET n'oubliez pas que la clé SSH ne passe jamais sur le réseau. Le serveur distant ne reçoit JAMAIS la clé, contrairement à un mot de passe, qui est non seulement envoyée sur le réseau, mais également au serveur distant. Pensez à cela la prochaine fois que vous ne savez pas quel mot de passe utiliser et essayez-en quelques-uns… qui sont peut-être utilisés sur d'autres comptes! Quels mots de passe avez-vous envoyé à ce serveur ???
9mjb

Réponses:


40

Si votre service SSH autorise l'authentification par mot de passe, votre serveur SSH connecté à Internet sera martelé jour et nuit par des réseaux réseau tentant de deviner les noms d'utilisateur et les mots de passe. Le réseau de bot n'a besoin d'aucune information, il peut simplement essayer des noms et des mots de passe populaires. Il y a énormément de personnes nommées john avec le mot de passe qwerty123. En dehors de toute autre chose, cela obstrue vos journaux.

Si votre service SSH n'autorise que l'authentification par clé publique, un attaquant a besoin d'une copie d'une clé privée correspondant à une clé publique stockée sur le serveur. Ils ne peuvent pas simplement faire des attaques aléatoires, ils doivent avoir une connaissance préalable de vos utilisateurs et pouvoir voler une clé privée sur le PC d'un utilisateur autorisé de votre serveur SSH.

Le fait que les clés privées soient souvent protégées par une longue phrase de passe revêt une importance secondaire.

Mise à jour:

Comme le soulignent les commentaires et l'expérience que j'ai vécue, le fait de déplacer votre service SSH du port 22 vers un port de numéro élevé a une incidence considérable sur le nombre de tentatives de connexion non autorisées figurant dans vos journaux. Cela vaut la peine d'être fait, mais je le considère comme une forme de sécurité par obscurité (un faux sentiment de sécurité). Tôt ou tard, les réseaux de robots vont implémenter une analyse de port furtive lente ou vous serez délibérément ciblé. Mieux vaut être préparé.

J'utilise toujours une phrase secrète longue pour protéger ma clé privée. Je suppose que cela revêt une importance particulière pour les appareils mobiles qui pourraient être plus facilement perdus ou volés.

Aussi, http://xkcd.com/538/

Sécurité


7
+1 sauf que l'authentification par clé publique ne fera rien pour que vos journaux soient bouchés par des bots essayant de se connecter. Pour arrêter cela, exécutez votre serveur SSH sur un port haut (9876 au lieu de 22). Ensuite, s'ils veulent vous frapper, ils doivent d'abord vous scanner, et les bots ne perdent généralement pas beaucoup de temps ... il y a beaucoup de serveurs SSH sur 22.
Ex Umbris

3
Vous ne plaisantez pas sur la taille du journal - mon / var / log / secure est passé de mégaoctets de tentatives de connexion à kilo-octets (avec uniquement mes enregistrements de connexion).
John C

2
+1 Intéressant, j'ai utilisé une authentification basée sur mot de passe depuis .. comme 10 ans maintenant .. lol .. D'accord, mes ports ssh exposés publiquement ne sont jamais le port 22. Pensez que les réseaux de zombies vont me scanner, et essayer port ils peuvent ?? Bonne information, merci.
James T Snell

2
@ExUmbris plutôt que de changer le port, vous devriez envisager d’utiliser fwknop: autorisation de paquet unique et coup de port . L’avantage ici devrait être évident: si vous ne permettez à personne de voir que le port est ouvert n’importe où sauf si on lui a donné accès au port en tapant avec SPA, ils ne peuvent même pas le trouver avec nmap et l'exploiter. C'est beaucoup mieux que la simple sécurité par l'obscurité.
Aculich

@aculich Changer de port n'est pas "la sécurité par l'obscurité". Tout ce que je fais, c'est empêcher les journaux de se remplir d'avertissements. Cependant, vous avez un bon argument pour améliorer la sécurité avec SPA.
Ex Umbris

8

La logique est qu'il y a beaucoup plus de combinaisons de clés SSH que de mots de passe, il est donc beaucoup plus difficile à deviner. L'utilisation de clés SSH vous permet également de désactiver l'authentification par mot de passe, ce qui signifie que la plupart des attaques automatisées faisant le tour d'Internet seront inutiles.

En ce qui concerne la sécurité physique, il n'y a aucune différence entre enregistrer un mot de passe et avoir une clé SSH non chiffrée sur votre appareil en cas de perte ou de vol. Le seul avantage que vous auriez, c'est que personne ne possède votre mot de passe et que vous pouvez théoriquement vous assurer que tous les périphériques possèdent des certificats SSH différents, vous pouvez donc simplement désactiver celui de votre téléphone.

Je crois qu'il est également possible de protéger par mot de passe les clés SSH.


Il convient toutefois de noter que les tentatives de forçage brutal de mots de passe contre sshd peuvent être détectées et protégées (par exemple par fail2ban), alors que toute personne ayant volé votre clé privée peut essayer des mots de passe aussi rapidement que leur ordinateur (ou cluster) le permet. leur. Ce n'est toujours pas une bonne attaque , mais ils ont considérablement amélioré leurs chances par rapport à une politique de fail2ban raisonnable.
Xiong Chiamiov


1

Les mots de passe peuvent également être compromis si votre clavier est surveillé "par-dessus votre épaule". De plus, l'utilisation de mots de passe similaires dans de nombreux endroits est une faiblesse, surtout si le mot de passe est parfois utilisé sur un ordinateur moins sécurisé avec des enregistreurs de frappe potentiels.

Vous avez raison de dire qu'une clé non chiffrée peut être lue sur le disque dur en cas de vol de l'ordinateur; cryptez-la avec un mot de passe.

Si votre ordinateur est compromis par un logiciel malveillant, vous êtes bourré quand même .. - Quelqu'un peut obtenir la clé cryptée et le journal des clés avec votre mot de passe.


1
Remarque: mais vous ne pouvez pas chiffrer votre clé avec un mot de passe si elle doit être utilisée par programme (c'est-à-dire dans un script).
TheStoryCoder
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.