350 votes

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

Voici ma situation : Je suis en train de mettre en place un harnais de test qui, à partir d'un client central, lancera un certain nombre d'instances de machines virtuelles, puis exécutera des commandes sur celles-ci par l'intermédiaire de ssh . Les machines virtuelles auront des noms d'hôtes et des adresses IP précédemment inutilisés, elles ne seront donc pas dans la liste des machines virtuelles. ~/.ssh/known_hosts sur le client central.

Le problème que j'ai, c'est que la première ssh exécutée contre une nouvelle instance virtuelle aboutit 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 de faire en sorte que le nouvel hôte soit déjà connu de la machine cliente, peut-être en utilisant une clé publique qui est déjà intégrée dans l'image de la machine virtuelle ? J'aimerais vraiment éviter d'avoir à utiliser Expect ou autre pour répondre à l'invite interactive si je le peux.

9 votes

Pour un environnement de test autonome et physiquement sécurisé, l'acceptation automatique des clés peut fonctionner parfaitement. Mais l'acceptation automatique des 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 de type "man-in-the-middle" que SSH pourrait offrir. Le site sólo Le moyen le plus sûr de s'assurer que vous êtes protégé contre les attaques MITM est de vérifier la clé publique de l'hôte par un canal de confiance hors bande. Il n'y a pas de moyen sûr d'automatiser cela sans mettre en place une infrastructure de signature de clé modérément compliquée.

16voto

Dominik Points 205

Vérifier l'empreinte digitale de chaque nouveau serveur/hôte. C'est le seul moyen d'authentifier le serveur. Sans cela, votre connexion SSH peut faire l'objet d'une attaque man-in-the-middle .

Ne pas utiliser l'ancienne valeur StrictHostKeyChecking=no dont jamais ne vérifie pas du tout l'authenticité du serveur. Bien que le signification de StrictHostKeyChecking=no est prévu pour être retourné plus tard.

La deuxième option, mais moins sûre, est d'utiliser StrictHostKeyChecking=accept-new qui a été introduit dans la version 7.6 (2017-10-03) d'OpenSSH :

Le premier "accept-new" acceptera automatiquement automatiquement les clés inconnues jusqu'à présent mais refusera les connexions pour des clés clés d'hôte modifiées ou invalides.

11voto

Zart Points 332

C'est ainsi que vous pouvez incorporer ssh-keyscan dans votre pièce :

---
# 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.results | map(attribute='stdout_lines') | list }}'

11voto

scottc Points 201

Pour faire cela correctement, ce que vous voulez vraiment faire, c'est collecter les clés publiques des hôtes des VM au fur et à mesure que vous les créez et les déposer dans un fichier dans le répertoire known_hosts format. Vous pouvez alors utiliser le -o GlobalKnownHostsFile=... qui pointe vers ce fichier, pour s'assurer que vous vous connectez à l'hôte auquel vous pensez devoir vous connecter. La manière de procéder dépend de la façon dont vous configurez les machines virtuelles, mais si possible, vous pouvez lire le fichier à partir du système de fichiers virtuel ou même faire en sorte que l'hôte imprime le contenu de ce fichier. /etc/ssh/ssh_host_rsa_key.pub pendant la configuration peut faire l'affaire.

Cela dit, cela peut ne pas être utile, selon le type d'environnement dans lequel vous travaillez et l'identité de vos adversaires potentiels. Un simple "stockage à la première connexion" (par le biais d'un scan ou simplement lors de la première connexion "réelle"), tel que décrit dans plusieurs autres réponses ci-dessus, peut s'avérer beaucoup plus facile et fournir un minimum de sécurité. Cependant, si vous faites cela, je vous suggère fortement de modifier le fichier hosts connu de l'utilisateur ( -o UserKnownHostsFile=... ) vers un fichier spécifique pour cette installation de test particulière ; cela évitera de polluer votre fichier d'hôtes connus personnel avec des informations de test et facilitera le nettoyage des clés publiques désormais inutiles lorsque vous supprimerez vos VM.

7voto

user387184 Points 5137

Ce serait une solution complète, acceptant la clé de l'hôte pour la première fois seulement

#!/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([]) }}'

7voto

Dan Moulding Points 46866

Je fais un script en une ligne, un peu long mais utile pour faire cette tâche pour les hôtes avec de multiples IPs, en utilisant dig y 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

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X