Ajoutez en toute sécurité un hôte (par exemple GitHub) au fichier SSH known_hosts


20

Comment puis-je ajouter une clé d'hôte au known_hostsfichier SSH en toute sécurité?

J'installe une machine de développement, et je veux (par exemple) empêcher gitde demander lorsque je clone un référentiel d' github.comutiliser SSH.

Je sais que je peux utiliser StrictHostKeyChecking=no(par exemple cette réponse ), mais ce n'est pas sûr.

Jusqu'à présent, j'ai trouvé ...

  1. GitHub publie leurs empreintes digitales clés SSH sur https://help.github.com/articles/github-s-ssh-key-fingerprints/

  2. Je peux utiliser ssh-keyscanpour obtenir la clé d'hôte pour github.com.

Comment combiner ces faits? Étant donné une liste pré-remplie d'empreintes digitales, comment puis-je vérifier que la sortie de ssh-keyscanpeut être ajoutée au known_hostsfichier?


Je suppose que je pose la question suivante:

Comment obtenir l'empreinte digitale d'une clé retournée par ssh-keyscan?

Supposons que j'ai déjà été édité par MITM pour SSH, mais que je peux faire confiance à la page GitHub HTTPS (car elle possède une chaîne de certificats valide).

Cela signifie que j'ai des clés d'hôte SSH (suspectes) (de ssh-keyscan) et des empreintes digitales de clé (de confiance). Comment vérifier l'un par rapport à l'autre?


Connexes: comment hacher la partie hôte de la sortie ssh-keyscan? Ou puis-je mélanger des hôtes hachés / non hachés known_hosts?


Pourquoi ne serait-il pas sécurisé pour votre cas d'utilisation?
quadruplebucky

StrictHostKeyChecking=noest vulnérable au MITM. Est ssh-keyscansécurisé contre MITM?
Roger Lipscombe

Je n'arrive pas à comprendre pourquoi je suis trop inquiet à propos de quelqu'un qui se fait passer pour un inconnu que je n'ai jamais rencontré à qui j'ai suffisamment confiance pour écrire du code que je suis sur le point de télécharger et d'exécuter ...
quadruplebucky

Parce que c'est mon code source dans un dépôt privé sur github, et je ne veux pas qu'un MITM (par exemple) introduise des changements malveillants lorsque je pousse des validations. Ce n'est qu'un exemple.
Roger Lipscombe

J'ai (pour le meilleur ou pour le pire) choisi de faire confiance à github. Je ne choisis pas de faire confiance à chaque lien réseau aléatoire entre moi et eux.
Roger Lipscombe

Réponses:


11

La partie la plus importante de l'ajout "sécurisé" d'une clé au known_hostsfichier consiste à obtenir l'empreinte de la clé auprès de l'administrateur du serveur. L'empreinte digitale doit ressembler à ceci:

2048 SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8 github.com (RSA)

Dans le cas de GitHub, normalement nous ne pouvons pas parler directement à un administrateur. Cependant, ils ont mis la clé sur leurs pages Web afin que nous puissions récupérer les informations à partir de là.

Installation manuelle des clés

1) Prenez une copie de la clé du serveur et récupérez son empreinte digitale. NB: Faites ceci avant de vérifier l'empreinte digitale.

$ ssh-keyscan -t rsa github.com | tee github-key-temp | ssh-keygen -lf -
# github.com:22 SSH-2.0-babeld-f3847d63
2048 SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8 github.com (RSA)

2) Obtenez une copie de l'empreinte digitale clé de l'administrateur du serveur - dans ce cas, accédez à la page contenant les informations sur github.com

  1. Allez sur github.com
  2. Accédez à la page d' aide (dans le menu à droite si vous êtes connecté; sinon au bas de la page d'accueil).
  3. Dans la section Mise en route , accédez à Connexion à GitHub avec SSH
  4. Allez à Test de votre connexion SSH
  5. Copiez l'empreinte SHA256 de cette page dans votre éditeur de texte pour une utilisation ultérieure.

3) Comparez les clés des deux sources

En les plaçant directement les uns au-dessus des autres dans un éditeur de texte, il est facile de voir si quelque chose a changé

2048 SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8 github.com (RSA) #key recovered from github website
2048 SHA256:nThbg6kXUpJ3Gl7E1InsaspRomtxdcArLviKaEsTGY8 github.com (RSA) #key recovered with keyscan

(Notez que la deuxième clé a été manipulée, mais elle ressemble assez à l'original - si quelque chose comme cela se produit, vous êtes sérieusement attaqué et devez contacter un expert en sécurité de confiance.)

Si les clés sont différentes, abandonnez la procédure et contactez un expert en sécurité

4) Si les clés se comparent correctement, vous devez installer la clé que vous avez déjà téléchargée

cat github-key-temp >> ~/.ssh/known_hosts

Ou à installer pour tous les utilisateurs d'un système (en tant que root):

cat github-key-temp >> /etc/ssh/ssh_known_hosts

Installation automatisée des clés

Si vous devez ajouter une clé pendant un processus de construction, vous devez suivre les étapes 1 à 3 du processus manuel ci-dessus.

Cela fait, examinez le contenu de votre github-key-tempfichier et créez un script pour ajouter ce contenu à votre fichier d'hôtes connu.

if ! grep github.com ~/.ssh/known_hosts > /dev/null
then
     echo "github.com ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==" >> ~/.ssh/known_hosts
fi

Vous devez maintenant vous débarrasser de toutes les sshcommandes StrictHostKeyCheckingdésactivées.


17

Vous pouvez mélanger les entrées hachées / non hachées dans votre fichier known_hosts.

Donc, si vous souhaitez ajouter une clé github, vous pouvez simplement faire:

ssh-keyscan github.com >> ~/.ssh/known_hosts

Si vous voulez qu'il soit haché, ajoutez -H

ssh-keyscan -H github.com >> ~/.ssh/known_hosts


1
Quelle est la différence entre haché / non haché? Je sais ce qu'est le hachage, mais pas pourquoi il est appliqué dans ce contexte.
Glen Thomas

3
Le hachage de vos entrées vous permet de masquer des informations sur les hôtes auxquels vous êtes connecté. Vérifiez la réponse acceptée à security.stackexchange.com/questions/56268/...
Wee

4
Cela ne répond pas à la question. L'utilisation de ssh-keyscan est soumise à une attaque de l'homme au milieu, ce qui signifie que la clé que vous stockez peut être une clé appartenant à l'attaquant essayant de s'introduire dans votre système. Veuillez voir ma réponse pour un moyen de vérifier les choses.
Michael

Att. Attirer l'attention sur les réponses qui ont toujours été incorrectes - "les deux meilleures réponses sont en fait peu sûres"
Peter Mortensen

6

Le moyen le plus simple est de récupérer manuellement les clés à l'aide de ssh-keyscan, de les vérifier manuellement:

$ ssh-keyscan -t rsa github.com | ssh-keygen -lf -
# github.com:22 SSH-2.0-libssh-0.7.0
2048 SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8 github.com (RSA)

Et ajoutez-les à votre script, qui portera alors la clé publique "faisant autorité".


J'ai les clés comme vous l'avez dit, comment les «ajouter à mon script»?
Glen Thomas

Soit en tant que fichier séparé, soit en tant que chaîne dans votre script.
Jakuje

Cette réponse est dangereuse car cachée dans le "vérifier manuellement" est un processus difficile. J'ai ajouté une réponse ci-dessous qui tente d'expliquer comment faire cela et utiliser les résultats en toute sécurité.
Michael

Att. Attirer l'attention sur les réponses qui ont toujours été incorrectes - "les deux meilleures réponses sont en fait peu sûres"
Peter Mortensen

1
@RogerLipscombe Je suis d'accord que la réponse pourrait être interprétée en toute sécurité - "les vérifier manuellement" n'est pas expliqué, mais si vous comprenez que cela signifie "suivre les instructions de la page de manuel ssh", alors ce serait probablement bien. Le risque ici est que quelqu'un ne le comprenne pas et puisse, par exemple, essayer des choses non sécurisées comme vérifier la clé après s'être connecté au serveur. C'est pourquoi j'ai appelé cette réponse "dangereuse" et l'autre "non sécurisée" - le détail de la façon dont vous vérifiez manuellement est l'élément le plus important. Merci de l'acceptation.
Michael
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.