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.