Question Puis-je ajouter automatiquement un nouvel hôte à known_hosts?


Voici ma situation: je suis en train de configurer un harnais de test qui va, à partir d’un client central, lancer un certain nombre d’instances de machines virtuelles puis exécuter des commandes sur celles-ci via ssh. Les machines virtuelles auront des noms d’hôte et des adresses IP inutilisés, elles ne seront donc pas dans la liste. ~/.ssh/known_hosts fichier sur le client central.

Le problème que je rencontre est que le premier ssh La commande exécutée sur une nouvelle instance virtuelle génère toujours une invite interactive:

The authenticity of host '[hostname] ([IP address])' can't be established.
RSA key fingerprint is [key fingerprint].
Are you sure you want to continue connecting (yes/no)?

Existe-t-il un moyen de contourner ce problème et d'obtenir que le nouvel hôte soit déjà connu de la machine client, peut-être en utilisant une clé publique déjà intégrée dans l'image de la machine virtuelle? J'aimerais vraiment éviter de devoir utiliser Expect ou quoi que ce soit pour répondre à l'invite interactive si je le peux.


217
2018-04-16 04:15


origine


Pour un environnement de test autonome et physiquement sécurisé, l'acceptation automatisée des clés peut parfaitement fonctionner. Mais accepter automatiquement les clés publiques dans un environnement de production ou sur un réseau non sécurisé (tel qu'Internet) contourne complètement toute protection contre les attaques interceptées que SSH se permettrait autrement. le seulement Un moyen efficace de vous assurer de votre sécurité contre les attaques MITM consiste à vérifier la clé publique de l'hôte via un canal approuvé hors bande. Il n’existe aucun moyen sûr de l’automatiser sans mettre en place une infrastructure de signature de clé moyennement compliquée. - Eil


Réponses:


Met le StrictHostKeyChecking option de nosoit dans le fichier de configuration, soit via -o :

ssh -o StrictHostKeyChecking=no username@hostname.com


126
2018-04-16 04:34



Cela vous laisse ouvert à l'homme au milieu des attaques, probablement pas une bonne idée. - JasperWallace
@JasperWallace, bien que ce soit généralement un bon conseil, le cas d'utilisation spécifique (déploiement de machines virtuelles de test et leur envoyer des commandes) devrait être suffisamment sécurisé. - Massimo
Cela donne un Warning: Permanently added 'hostname,1.2.3.4' (RSA) to the list of known hosts. Pour éviter l'avertissement et pour éviter que l'entrée ne soit ajoutée à un fichier known_hosts, je fais: ssh -o StrictHostKeyChecking=no -o LogLevel=ERROR -o UserKnownHostsFile=/dev/null username@hostname.com - Peter V. Mørch
Le vote préférentiel, car cela ne répond pas à la question et ouvre de sérieuses vulnérabilités en matière de sécurité. - marcv81
@Mnebuerquo: Si vous vous inquiétiez pour la sécurité, vous n'auriez rien à voir avec cette question. Vous avez devant vous la clé d'hôte correcte, collectée à partir de la console du système auquel vous souhaitez vous connecter, et vous la vérifiez manuellement lors de la première connexion. Vous ne feriez certainement rien "automatiquement". - Ignacio Vazquez-Abrams


OMI, la meilleure façon de faire est la suivante:

ssh-keygen -R [hostname]
ssh-keygen -R [ip_address]
ssh-keygen -R [hostname],[ip_address]
ssh-keyscan -H [hostname],[ip_address] >> ~/.ssh/known_hosts
ssh-keyscan -H [ip_address] >> ~/.ssh/known_hosts
ssh-keyscan -H [hostname] >> ~/.ssh/known_hosts

Cela garantira qu'il n'y a pas d'entrées en double, que vous êtes couvert à la fois pour le nom d'hôte et l'adresse IP, et que la sortie sera également hachée, une mesure de sécurité supplémentaire.


209
2017-09-27 20:51



Pourquoi avez-vous besoin des 3 ssh-keyscan? Ne pouvez-vous pas vous contenter du premier, car cela fonctionne à la fois pour hostname et ip? - Robert
Pouvez-vous être sûr que la machine qui répond à la demande ssh-keyscan est vraiment celle à laquelle vous voulez parler? Sinon, vous vous êtes ouvert à un homme au milieu de l'attaque. - JasperWallace
@JasperWallace Oui, pour cela, vous avez besoin d'au moins l'empreinte digitale ou, mieux, de la clé publique. Dans ce cas, vous pouvez l'ajouter directement à known_hosts, ce qui rend la question sans objet. Si vous n'avez que l'empreinte digitale, vous devrez écrire une étape supplémentaire pour vérifier la clé publique téléchargée avec votre empreinte digitale ...
Appels à ssh-keyscan échouaient pour moi car mon hôte cible ne prend pas en charge le type de clé par défaut de la version 1. Ajouter -t rsa,dsa à la commande corrigé cela. - phasetwenty
C'est probablement une mauvaise idée. Vous vous ouvrez à une attaque de l'homme du milieu en mettant à jour ces clés. Pour éviter les doublons, vérifiez le statut de retour de ssh-keygen -F [address] au lieu. medium.com/@wblankenship/… - retrohacker


Pour les paresseux:

ssh-keyscan <host> >> ~/.ssh/known_hosts

78
2017-09-25 10:03



+1 pour être coupable du chef d'accusation. Merci. - SaxDaddy
Vulnérable aux attaques MITM. Vous ne vérifiez pas l'empreinte digitale de la clé. - Mnebuerquo
@Mnebuerquo Vous dites quoi faire mais pas comment, ce qui serait utile. - Jim
@jameshfisher Oui, il est vulnérable aux attaques MITM, mais avez-vous déjà comparé l'empreinte RSA, qui vous a été montrée avec celle du serveur, lorsque vous le faisiez manuellement? Non? Donc, cette réponse est le moyen de le faire pour vous. Si oui, vous ne devriez pas utiliser cette réponse et le faire manuellement ou mettre en œuvre d'autres mesures de sécurité ... - fivef
@Mnebuerquo Je serais vraiment heureux si vous nous fournissiez également un meilleur moyen de gérer cela, lorsque nous devons cloner un référentiel à l'aide de scripts batch sans assistance et que nous souhaitons ignorer cette invite. Merci de faire la lumière sur une vraie solution si vous pensez que ce n’est pas la bonne! - Waqas Shah


Comme mentionné précédemment, l’utilisation de la numérisation au clavier serait le moyen approprié et discret de procéder.

ssh-keyscan -t rsa,dsa HOST 2>&1 | sort -u - ~/.ssh/known_hosts > ~/.ssh/tmp_hosts
mv ~/.ssh/tmp_hosts ~/.ssh/known_hosts

Ce qui précède fera l'affaire pour ajouter un hôte, UNIQUEMENT s'il n'a pas encore été ajouté. Il n’est pas non plus protégé contre la concurrence. vous ne doit pas exécutez l'extrait de code sur la même machine d'origine plusieurs fois en même temps, car le fichier tmp_hosts peut être obstrué, ce qui finit par faire gonfler le fichier known_hosts ...


38
2018-03-06 09:00



Existe-t-il un moyen de vérifier si la clé est dans unknown_hosts avant  ssh-keyscan? La raison en est que cela nécessite du temps et une connexion réseau supplémentaire. - utapyngo
La version originale de ce fichier par l’affiche originale cat ~/.ssh/tmp_hosts > ~/.ssh/known_hosts, mais une modification ultérieure l'a changé en >>. En utilisant >> est une erreur. Cela va à l’encontre du but de l’unicité de la première ligne et le poussera à vider de nouvelles entrées dans known_hostsà chaque fois qu'il court. (Vient de poster une modification pour le rendre à nouveau.) - paulmelnikow
Ceci est sujet aux mêmes attaques MITM que les autres. - Mnebuerquo
@utapyngo ssh-keygen -F vous donnera l’empreinte digitale actuelle. S'il revient vide avec le code de retour de 1, vous ne l'avez pas. S'il imprime quelque chose et que le code de retour est 0, il est déjà présent. - Rich L
Si vous vous souciez vraiment de MITM, déployez des enregistrements DNSSEC et SSHFP ou utilisez un autre moyen sécurisé de distribution des clés. Cette solution de kludge n'aura aucune pertinence. - Zart


Vous pourriez utiliser ssh-keyscan commande pour saisir la clé publique et l'ajouter à votre known_hosts fichier.


18
2018-04-16 05:09



Assurez-vous de vérifier l'empreinte digitale pour vous assurer que c'est la clé correcte. Sinon, vous vous ouvrez aux attaques MITM. - Mnebuerquo
@Mnebuerquo Fair pointe dans le contexte général, mais pourquoi quelqu'un essaierait-il de collecter des clés par programme s'il savait déjà quelle était la clé correcte? - Brian Cline
Ce n'est pas la façon de le faire. MITM. - jameshfisher


Voici comment vous pouvez intégrer ssh-keyscan dans votre jeu:

---
# ansible playbook that adds ssh fingerprints to known_hosts
- hosts: all
  connection: local
  gather_facts: no
  tasks:
  - command: /usr/bin/ssh-keyscan -T 10 {{ ansible_host }}
    register: keyscan
  - lineinfile: name=~/.ssh/known_hosts create=yes line={{ item }}
    with_items: '{{ keyscan.stdout_lines }}'

6
2018-02-03 03:12



Souhaitez-vous télécharger un fichier known_hosts valide connu ou effectuez-vous une analyse ssh-keys et exportez-vous la sortie dans known_hosts sans vérifier les empreintes digitales? - Mnebuerquo
Ceci est simplement la sortie de la sortie d'un keyscan, oui. En pratique, cela revient à StrictHostKeyChecking = no, mais avec la mise à jour silencieuse de known_hosts sans modifier les options ssh. Cette solution aussi ne fonctionne pas bien car ssh-keys peut retourner plusieurs lignes ce qui fait que cette tâche est toujours marquée comme 'modifiée' - Zart
Ce n'est pas la façon de le faire. MITM. - jameshfisher
@jameshfisher Je serais vraiment heureux si vous nous fournissiez également un meilleur moyen de gérer cela, lorsque nous devons cloner un référentiel à l'aide de scripts batch sans assistance et que nous souhaitons ignorer cette invite. Merci de faire la lumière sur une vraie solution si vous pensez que ce n’est pas la bonne! S'il vous plaît laissez-nous savoir "comment" le faire, si vous pensez que ce n'est pas la bonne façon de le faire! - Waqas Shah


J'ai eu un problème similaire et j'ai constaté que certaines des réponses fournies ne m'apportaient qu'une partie du chemin vers une solution automatisée. Voici ce que j'ai fini par utiliser, j'espère que cela aide:

ssh -o "StrictHostKeyChecking no" -o PasswordAuthentication=no 10.x.x.x

Il ajoute la clé à known_hosts et ne demande pas le mot de passe.


5
2017-10-21 17:27



Vulnérable aux attaques MITM. Vous ne vérifiez pas les empreintes digitales. - Mnebuerquo
Personne ne vérifie l'empreinte digitale. - Brendan Byrd
Ce n'est pas la façon de le faire. MITM. - jameshfisher


ce serait une solution complète, n'acceptant la clé d'hôte que pour la première fois

#!/usr/bin/env ansible-playbook
---
- name: accept ssh fingerprint automatically for the first time
  hosts: all
  connection: local
  gather_facts: False

  tasks:
    - name: "check if known_hosts contains server's fingerprint"
      command: ssh-keygen -F {{ inventory_hostname }}
      register: keygen
      failed_when: keygen.stderr != ''
      changed_when: False

    - name: fetch remote ssh key
      command: ssh-keyscan -T5 {{ inventory_hostname }}
      register: keyscan
      failed_when: keyscan.rc != 0 or keyscan.stdout == ''
      changed_when: False
      when: keygen.rc == 1

    - name: add ssh-key to local known_hosts
      lineinfile:
        name: ~/.ssh/known_hosts
        create: yes
        line: "{{ item }}"
      when: keygen.rc == 1
      with_items: '{{ keyscan.stdout_lines|default([]) }}'

5
2017-11-23 13:51



Ce n'est pas la façon de le faire. MITM. - jameshfisher


Je cherchais donc un moyen banal de contourner l'interaction manuelle d'un hôte non connu consistant à cloner un dépôt Git, comme indiqué ci-dessous:

brad@computer:~$ git clone git@bitbucket.org:viperks/viperks-api.git
Cloning into 'viperks-api'...
The authenticity of host 'bitbucket.org (104.192.143.3)' can't be established.
RSA key fingerprint is 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40.
Are you sure you want to continue connecting (yes/no)?

Notez l'empreinte de la clé RSA ...

Donc, ceci est une chose SSH, cela fonctionnera pour git sur SSH et seulement les choses liées à SSH en général ...

brad@computer:~$ nmap bitbucket.org --script ssh-hostkey

Starting Nmap 7.01 ( https://nmap.org ) at 2016-10-05 10:21 EDT
Nmap scan report for bitbucket.org (104.192.143.3)
Host is up (0.032s latency).
Other addresses for bitbucket.org (not scanned): 104.192.143.2 104.192.143.1 2401:1d80:1010::150
Not shown: 997 filtered ports
PORT    STATE SERVICE
22/tcp  open  ssh
| ssh-hostkey:
|   1024 35:ee:d7:b8:ef:d7:79:e2:c6:43:9e:ab:40:6f:50:74 (DSA)
|_  2048 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40 (RSA)
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 42.42 seconds

Tout d’abord, installez nmap sur votre pilote quotidien. nmap est très utile pour certaines tâches, telles que la détection des ports ouverts et ceci - la vérification manuelle des empreintes SSH. Mais revenons à ce que nous faisons.

Bien. Je suis soit compromis aux multiples endroits et machines que j'ai vérifiées - soit à l'explication la plus plausible de tout ce qui se passe, c'est ce qui se passe.

Cette "empreinte" est simplement une chaîne raccourcie avec un algorithme à sens unique pour plus de commodité, au risque que plusieurs chaînes se résolvent en une même empreinte. Ça arrive, on appelle ça des collisions.

Quoi qu'il en soit, revenons à la chaîne d'origine que nous pouvons voir dans le contexte ci-dessous.

brad@computer:~$ ssh-keyscan bitbucket.org
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-128
no hostkey alg
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-129
bitbucket.org ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-123
no hostkey alg

Nous avons donc à l’avance le moyen de demander une forme d’identification à l’hôte original.

À ce stade, nous sommes manuellement aussi vulnérables qu'automatiquement - les chaînes correspondent, nous avons les données de base qui créent l'empreinte, et nous pourrions demander ces données de base (prévention des collisions) à l'avenir.

Maintenant, utiliser cette chaîne de manière à éviter de poser des questions sur l'authenticité d'un hôte ...

Dans ce cas, le fichier known_hosts n'utilise pas d'entrées en texte brut. Vous connaîtrez les entrées hachées quand vous les verrez, elles ressemblent à des hachages avec des caractères aléatoires au lieu de xyz.com ou 123.45.67.89.

brad@computer:~$ ssh-keyscan -t rsa -H bitbucket.org
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-128
|1|yr6p7i8doyLhDtrrnWDk7m9QVXk=|LuKNg9gypeDhfRo/AvLTAlxnyQw= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==

La première ligne de commentaire apparaît avec exagération - mais vous pouvez vous en débarrasser avec une simple redirection via la convention ">" ou ">>".

Comme j'ai fait de mon mieux pour obtenir des données non corrompues pouvant être utilisées pour identifier un "hôte" et une relation de confiance, je vais ajouter cette identification à mon fichier known_hosts dans mon répertoire ~ / .ssh. Puisqu'il sera maintenant identifié en tant qu'hôte connu, je ne recevrai pas l'invite mentionnée ci-dessus lorsque vous étiez jeune.

Merci de rester avec moi, voilà. J'ajoute la clé RSA bitbucket afin de pouvoir interagir avec mes référentiels git de manière non interactive dans le cadre d'un flux de travail CI, mais peu importe ce que vous faites.

#!/bin/bash
cp ~/.ssh/known_hosts ~/.ssh/known_hosts.old && echo "|1|yr6p7i8doyLhDtrrnWDk7m9QVXk=|LuKNg9gypeDhfRo/AvLTAlxnyQw= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==" >> ~/.ssh/known_hosts

Donc, c'est comme ça que vous restez vierge pour aujourd'hui. Vous pouvez faire la même chose avec github en suivant des instructions similaires pendant votre temps libre.

J'ai vu tant de messages de débordement de pile vous demandant d'ajouter par programmation la clé à l'aveuglette sans vérification. Plus vous vérifiez la clé de différentes machines sur différents réseaux, plus vous pouvez avoir confiance que l'hôte est celui qu'il dit, et c'est ce que vous pouvez espérer de mieux avec cette couche de sécurité.

FAUX ssh -oStrictHostKeyChecking = pas de nom d'hôte [commande]

FAUX ssh-keyscan -t rsa -H nom_hôte >> ~ / .ssh / connus_hôtes

Ne faites aucune des choses ci-dessus, s'il vous plaît. Vous avez la possibilité d'augmenter vos chances d'éviter que quelqu'un n'écoute vos transferts de données via un homme au centre de l'attaque - saisissez cette opportunité. La différence est de vérifier littéralement que la clé RSA que vous avez est bien celle du serveur authentique et que vous savez maintenant comment obtenir ces informations pour les comparer afin que vous puissiez faire confiance à la connexion. N'oubliez pas que plus de comparaisons entre différents ordinateurs et réseaux augmenteront généralement votre capacité à faire confiance à la connexion.


4
2017-10-05 21:18



Je pense que c'est la meilleure solution à ce problème. Cependant, soyez très prudent lorsque vous utilisez Nmap sur quelque chose comme Amazon EC2, j'ai reçu un avertissement concernant l'analyse du port effectué par Nmap! Remplissez leur formulaire avant de faire du scan de port! - Waqas Shah
...Ben ouais. Je ne sais pas pourquoi vous feriez la numérisation de port d'EC2. Si vous êtes connecté à votre compte, vous pouvez simplement obtenir les clés des machines réelles. C'est plus pour les machines que vous n'avez pas le contrôle. Je suppose que vous auriez un ordinateur local non soumis aux restrictions d’analyse de port AWS. Mais, si vous êtes dans cette situation extrême où vous devez exécuter nmap avec AWS, je suppose que cet avertissement serait utile. - BradChesney79
Utiliser nmap pour lire la clé d’hôte SSH sur votre poste de travail, puis approuver cette valeur n’est pas différent de la connexion via SSH avec StructHostKeyChecking désactivé. C'est tout aussi vulnérable à une attaque de type homme du milieu. - Micah R Ledbetter
... @ MicahRLedbetter c'est pourquoi j'ai suggéré qu '"un plus grand nombre de comparaisons entre différents ordinateurs et réseaux augmenterait généralement votre capacité à faire confiance à la connexion". Mais, c'est mon point. Si vous ne vérifiez jamais votre hôte cible à partir d'un seul ensemble de conditions d'environnement, comment sauriez-vous qu'il existe des anomalies? Avez-vous eu de meilleures suggestions? - BradChesney79
C'est un théâtre de sécurité. Faire quelque chose de compliqué pour créer l'apparence d'une plus grande sécurité. Peu importe le nombre de méthodes différentes que vous utilisez pour demander la clé à l'hôte. C'est comme demander à la même personne plusieurs fois si vous pouvez lui faire confiance (peut-être que vous appelez, envoyez un courrier électronique, du texte ou un courrier postal). Ils diront toujours oui, mais si vous demandez à la mauvaise personne, ce n'est pas grave. - vastlysuperiorman


Je fais un script à une ligne, un peu long mais utile pour effectuer cette tâche pour les hôtes avec plusieurs adresses IP, en utilisant dig et bash

(host=github.com; ssh-keyscan -H $host; for ip in $(dig @8.8.8.8 github.com +short); do ssh-keyscan -H $host,$ip; ssh-keyscan -H $ip; done) 2> /dev/null >> .ssh/known_hosts

3
2018-04-18 21:01





Les éléments suivants évitent les entrées en double dans ~ / .ssh / known_hosts:

if ! grep "$(ssh-keyscan github.com 2>/dev/null)" ~/.ssh/known_hosts > /dev/null; then
    ssh-keyscan github.com >> ~/.ssh/known_hosts
fi

3
2017-07-02 11:41



Ce n'est pas la façon de le faire. MITM. - jameshfisher