web-dev-qa-db-fra.com

Mot de passe SSH vs authentification par clé

On m'a généralement dit que l'authentification par clé publique est fortement préférée à l'authentification par mot de passe pour SSH. Cependant, notre ancien administrateur était contre les clés publiques et ne délivrait que des mots de passe et a pris soin d'utiliser des mots de passe différents pour différents serveurs (mots de passe générés par pwgen; ils sont raisonnablement difficiles à forcer brutalement, mais garanti à écrire par l'utilisateur). Je voudrais donc demander:

  1. L'utilisation du mot de passe a-t-elle plus de sens pour l'administration (non root avec plus ou moins de capacités Sudo) de connexion complète à Shell. Étant donné que les mots de passe sont différents là où la clé ne le serait probablement pas et le mot de passe est également utilisé pour Sudo.
  2. Était-ce OK même pour un compte spécial pour le téléchargement sftp (limité à un répertoire particulier) où le mot de passe se retrouve dans un fichier sur un autre serveur, car le téléchargement doit être sans surveillance? La clé publique finirait par être stockée non chiffrée sur le même autre serveur.
25
Jan Hudec

C'est un peu comme ça… Je suis divorcée et j'ai une ex-femme au vitriol. J'ai aussi trois grands garçons qui, comme la plupart des garçons, peuvent être oublieux, perdre des choses et qui aiment aussi leur maman. Quand mes garçons sont devenus assez vieux pour avoir besoin d'une clé de ma maison, j'ai dû prendre une décision: dois-je utiliser une serrure à clé ou l'un de ces claviers numériques? Si j'utilise la serrure à clé, il était certain que mes fils perdraient régulièrement des clés; Je recevrais des appels pour rentrer du travail pour les laisser entrer; et il y avait une grande possibilité que je devrais remplacer la serrure ou la refixer de temps en temps parce que le nombre de "clés perdues" (ou la probabilité que mon ex-femme vitriolique en possédait une) atteignait une limite inconfortable.

Bien que ce ne soit peut-être pas le plus sûr au monde, avec le verrou numérique, je n'avais aucune inquiétude quant à la perte des clés; Je pouvais envoyer à mes fils le combo du travail (sans rentrer à la maison) quand ils l'avaient oublié; et je pouvais le changer périodiquement quand je sentais qu'il était compromis. Je pouvais également décider combien de temps et/ou complexe je voulais. Si je pensais que mon ex l'avait, je pourrais aussi le changer. Coût total de possession beaucoup plus simple et moins élevé.

La serrure à clé est comme PK. Le verrou numérique est comme les mots de passe. En fin de compte, je peux vous dire que je suis beaucoup plus en sécurité avec le verrou numérique, car je choisis mon propre destin et je peux le faire aussi dynamiquement que je le souhaite. Et rappelez-vous, la réalité est que la porte n'est qu'un des accès à ma maison.

21
Tek Tengu

Dans le cas de l'authentification par mot de passe, l'utilisateur se souvient du mot de passe et est responsable de ne le révéler à personne. Avec l'authentification basée sur la clé publique, l'utilisateur possède la clé privée quelque part, stockée dans un fichier.

Les utilisateurs préfèrent l'authentification par clé car elle est plus pratique à utiliser dans la pratique (les clients SSH utiliseront la clé de manière transparente, donc cela ne nécessite aucun effort pour l'utilisateur humain). Cependant, l'authentification par clé implique les éléments suivants:

  • L'utilisateur gère lui-même les clés, et quelles clés sont acceptées ou non, en plaçant les clés publiques dans son .ssh/authorized_keys fichier.
  • La clé privée est nécessairement stockée sous forme de fichier quelque part, peut-être (mais pas nécessairement) protégée par une phrase secrète.
  • Le choix de la phrase de passe locale (ou son absence) est complètement hors de portée du sysadmin du serveur.

Certains administrateurs système préfèrent que les utilisateurs utilisent l'authentification par clé car ils ne font pas confiance aux utilisateurs humains pour se souvenir d'un mot de passe fort; ils croient que la sécurité d'un fichier de clé privée sera plus facile à maintenir par les utilisateurs moyens que la génération et l'utilisation d'un mot de passe fort. La plupart des administrateurs système, cependant, considèrent que les fichiers de clés privées sont une vulnérabilité flagrante, alors qu'avec les mots de passe ils ont des mécanismes d'atténuation: ils peuvent appliquer des "règles de mot de passe" lorsque le mot de passe est choisi, et ils peuvent bloquer ou réinitialiser de manière centralisée les mots de passe quand ils le souhaitent. C'est vraiment un équilibre entre combien le sysadmin fait confiance aux utilisateurs (confiance en leur compétence, pas en leur honnêteté) et combien un contrôle-freak le sysadmin est.

11
Tom Leek

Mots de passe

  • peut être facile à oublier.
  • peut être facile à deviner/craquer.
  • peut avoir différentes contraintes en termes de caractères que vous pouvez utiliser, de longueur ...
  • sont très souvent réutilisés sur différents services.
  • avez-vous entendu parler de la fuite de cette base de données de mots de passe?

Défi-réponse

Clés SSH (ou jeton api)

  • ne doivent pas être mémorisés (stockés sur votre ordinateur).
  • sont plus difficiles à deviner/craquer (par rapport à une attaque par dictionnaire).
  • n'ont pas besoin d'être partagés sur différents services.

Asymétrie/force du mot de passe.

  • La plupart des solutions de clés publiques/privées utilisent des clés asymétriques (je n'ai pas entendu autrement mais je n'y mettrais pas mon argent). Si votre clé publique est compromise, cela ne permet pas à un attaquant d'accéder au système.
  • Les bases de données de mots de passe doivent avoir un cryptage unidirectionnel; et celui qui est assez fort ou qui gaspille suffisamment de cycles de calcul qu'il devient difficile de forcer brutalement.

Réinitialiser le workflow

L'utilisation de mots de passe ou de clés ssh n'est pas pertinente ici, à un moment donné, un utilisateur va soit oublier son mot de passe (par exemple, il avait VERR MAJUSCULES quand il l'a créé ...) soit réinstaller son système (par exemple Time Machine/Mises à jour ...). Comment gérez-vous de telles situations? Vous devrez changer le mot de passe/la clé (en supposant que le précédent est compromis) et communiquer en toute sécurité le nouveau à l'utilisateur.

Voir réponse acceptée . Si votre enfant essaie d'entrer dans votre maison. Le défi est que vous devez d'abord confirmer que c'est votre fils (par exemple, vous savez que c'est leur numéro de téléphone, vous reconnaissez leur voix, c'est la partie du défi ) . Le flux de travail très courant consiste à générer un mot de passe temporaire/unique et à demander à votre fils de changer son mot de passe. Mais cela pourrait très bien être: donnez-leur un mot de passe unique et laissez-les télécharger leur nouveau jeton clé/api ssh. Heck, vous ne pourriez même pas prendre la peine de les laisser changer leurs informations d'identification et les laisser à distance si votre clavier/verrou est connecté.

Remarque: rien n'empêche votre ex-femme de collusion avec votre fils afin de vous tromper et d'accéder à la maison.

Quel est le meilleur?

Cela dépend de votre cas d'utilisation et des pertes acceptables. Étant donné que les deux mots de passe/clés ssh/jetons api sont détenus par un utilisateur, l'utilisateur peut les partager. Si vous prenez en charge l'authentification par mot de passe et que les mots de passe sont divulgués, certains de vos utilisateurs devront peut-être changer leurs mots de passe sur des sites Web externes - simplement parce qu'ils réutilisent les mêmes mots de passe ailleurs. Si vous utilisez des clés publiques/privées, vous avez moins de soucis.

Vous n'avez pas à choisir l'un ou l'autre. Vous pouvez utiliser les deux! Par exemple. vous pouvez avoir à la fois un verrou (votre copie personnelle) et un cadenas numérique (invités).

8
dnozay

Les mots de passe peuvent être forcés brutalement. Deviner une clé publique est tellement impossible qu'il peut être considéré comme parfaitement sécurisé. Les mots de passe ne peuvent être attribués qu'un seul par utilisateur, tandis qu'un seul compte d'utilisateur peut avoir plusieurs clés installées. Si je perds mon ordinateur portable, je n'ai qu'à supprimer l'entrée de la clé de mon ordinateur portable dans le fichier authorised_keys, et ce compte est toujours accessible depuis mes autres appareils avec leurs propres clés. Les clés individuelles peuvent également recevoir des restrictions de commande, permettant une connexion automatisée qui exécute une commande spécifique mais pas un shell complet. La seule façon dont les mots de passe sont utiles est de partager l'accès à un compte existant sans se connecter (pour télécharger la nouvelle clé) et cela ouvre le trou de sécurité d'avoir à changer ce mot de passe si vous devez supprimer cet accès où une clé est individuelle.

5
mikebabcock

Sujet intéressant, pour moi le plus sûr est le mot de passe, j'utilise 4 mots de passe différents pour différentes choses en fonction de la sécurité requise, par exemple pour un site comme celui-ci, j'utiliserai quelque chose comme (mexico1970) dont je me fiche s'il se fissure car je viens publier sur le site et il n'y a aucune information de carte de crédit ou toute autre information importante à protéger, alors j'aurai un autre mot de passe pour des problèmes plus importants, disons pour un e-mail quelque chose comme (!! carmelita.99) puis j'en aurai un pour l'utilisateur du serveur accès (XrE.67-73up) puis un autre pour l'accès root et pour les trucs bancaires, (!!. CeRto-49er) puis je m'assure de ne pas écrire ces mots de passe, je les mémorise, chaque fois que je me connecte à mes serveurs je fais assurez-vous que l'empreinte ssh est déjà ajoutée à mes hôtes connus, sinon il pourrait y avoir une attaque MITM en cours, assurez-vous également que le certificat TLS/SSL de la banque est valide et ne partagez jamais les mots de passe.

Ce que je déteste, ce sont les services qui vous obligent à définir un mot de passe si impossibles que vous devez l'écrire, ou certains autres qui ont des politiques de mot de passe où je dois utiliser un mot de passe différent chaque mois et ne peux pas utiliser les 5 derniers mots de passe utilisés, qui est juste stupide, car il n'y a pas de sécurité dans l'écriture des mots de passe, changer les mots de passe est quelque chose de bien mais cela ne devrait pas être appliqué, d'autre part, les certificats sont susceptibles d'être perdus ou même compromis, pensez que vous avez quelqu'un avec accès à votre ordinateur ils peuvent installer des enregistreurs de frappe ou également obtenir les certificats. il n'y a donc rien qui vous protège, mais les certificats ne sont certainement pas plus sûrs que les mots de passe. avec les serveurs, j'ai un sentiment de sécurité lorsque plusieurs mécanismes sont définis, disons un VPN pour accéder à une machine d'où vous pouvez vous connecter à vos serveurs via SSH, obscurité? peut-être mais n'ont jamais été piratés.

À la vôtre, j'aime un site où je peux poster sans mot de passe.

3
Carlos Ruiz