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

Je cherchais donc un moyen banal de contourner l'interaction manuelle de l'hôte inconnu pour cloner un repo 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, c'est un truc SSH, cela fonctionnera pour git sur SSH et juste pour 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 choses, comme la détection des ports ouverts et la vérification manuelle des empreintes SSH. Mais, revenons à ce que nous faisons.

Bien. Soit je suis compromis par les multiples endroits et machines où je l'ai vérifié, soit l'explication la plus plausible, à savoir que tout va pour le mieux, est ce qui se passe.

Cette "empreinte digitale" n'est qu'une chaîne de caractères raccourcie à l'aide d'un algorithme à sens unique pour notre confort humain, au risque que plusieurs chaînes de caractères donnent la même empreinte digitale. Cela arrive, on appelle cela des collisions.

Quoi qu'il en soit, revenons à la chaîne originale 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

Ainsi, à l'avance, nous avons un moyen de demander une forme d'identification à l'hôte d'origine.

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

Maintenant, il faut utiliser cette chaîne de manière à éviter de demander l'authenticité d'un hôte...

Dans ce cas, le fichier known_hosts n'utilise pas d'entrées en texte clair. Vous reconnaî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 de façon exaspérante - 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 contaminées à utiliser pour identifier un "hôte" et la confiance, je vais ajouter cette identification à mon fichier known_hosts dans mon répertoire ~/.ssh. Puisqu'il sera désormais identifié comme un hôte connu, je n'obtiendrai pas l'invite mentionnée ci-dessus lorsque vous étiez jeune.

Merci d'être resté avec moi, voilà. J'ajoute la clé RSA de bitbucket pour pouvoir interagir avec mes dépôts git de manière non interactive dans le cadre d'un workflow CI, mais faites ce que vous voulez.

#!/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 tu restes vierge pour aujourd'hui. Vous pouvez faire de même avec github en suivant les mêmes instructions à votre rythme.

J'ai vu tellement d'articles de stack overflow vous disant d'ajouter la clé de façon programmatique et à l'aveuglette sans aucune sorte de vérification. Plus vous vérifiez la clé à partir de différentes machines sur différents réseaux, plus vous pouvez avoir confiance dans le fait que l'hôte est celui qu'il prétend être - et c'est le mieux que vous puissiez espérer de cette couche de sécurité.

MAUVAIS ssh -oStrictHostKeyChecking=no hostname [command]

MAUVAIS ssh-keyscan -t rsa -H hostname >> ~/.ssh/known_hosts

Ne faites pas l'une ou l'autre 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 une attaque de type "man in the middle" - saisissez cette opportunité. La différence est de vérifier littéralement que la clé RSA que vous avez est celle du serveur de bonne foi et maintenant vous savez comment obtenir cette information pour les comparer afin de pouvoir faire confiance à la connexion. Rappelez-vous qu'un plus grand nombre de comparaisons à partir de différents ordinateurs et réseaux augmentera généralement votre capacité à faire confiance à la connexion.

Voici comment faire une collection d'hôtes

définir une collection d'hôtes

ssh_hosts:
  - server1.domain.com
  - server2.domain.com
  - server3.domain.com
  - server4.domain.com
  - server5.domain.com
  - server6.domain.com
  - server7.domain.com
  - server8.domain.com
  - server9.domain.com

Définissez ensuite deux tâches pour ajouter les clés aux hôtes connus :

- command: "ssh-keyscan {{item}}"
   register: known_host_keys
   with_items: "{{ssh_hosts}}"
   tags:
     - "ssh"

 - name: Add ssh keys to know hosts
   known_hosts:
     name: "{{item.item}}"
     key: "{{item.stdout}}"
     path: ~/.ssh/known_hosts
   with_items: "{{known_host_keys.results}}"

Si vous avez déjà un .pub alors qu'on vous parle de ssh-keyscan vous demande de risquer une attaque MitM.

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 et exécutera ensuite des commandes sur celles-ci via ssh.

Cette réponse de StackOverflow a une meilleure réponse plus correcte. Vous devez obtenir le .pub à partir d'une source de confiance : l'amorceur de votre système doit appeler la maison et fournir le fichier à un système de gestion.

#!/usr/bin/env bash

: "${pubkey=-"$2"}"
: "${host=-"$1"}"

TMP_KNOWN_HOSTS=$(mktemp)
echo "${host}" "$(cat "${pubkey}")" > "${TMP_KNOWN_HOSTS}"

ssh-keygen -H -f "${TMP_KNOWN_HOSTS}"
ssh-keygen -F "${host}" -f "${TMP_KNOWN_HOSTS}" | tee ~/.ssh/known_hosts

shred "${TMP_KNOWN_HOSTS}.old"
rm -f "${TMP_KNOWN_HOSTS}" "${TMP_KNOWN_HOSTS}.old"

Vous pouvez essayer cela avec vos clés d'hôte locales :

$ for pubkey in /etc/ssh/ssh_host_*.pub; do ./add_pubkey localhost "${pubkey}"; done

Puisque ce sont des "VM", vous devriez pouvoir y accéder par d'autres moyens (ex : monter le système de fichiers), et obtenir les clés.

Une fois que vous avez obtenu les clés publiques, vous pouvez construire votre "known_hosts" (concaténation des clés publiques).

Ou l'inverse : pousser une clé privée connue sur chaque esclave en accédant au système de fichiers des VM.

Cette solution est excessive pour les cas simples où vous maîtrisez votre environnement, mais elle n'est pas sensible aux attaques de type "men-in-the-middle"...

if ! ssh-keygen -F HOST; then
    ssh-keyscan HOST >> ~/.ssh/known_hosts
fi

ou dans le cas d'un port personnalisé :

if ! ssh-keygen -F [HOST]:PORT; then
    ssh-keyscan -p PORT HOST >> ~/.ssh/known_hosts
fi

Mais cela est vulnérable au MITM.