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

Cela doit être un cas rare mais j'avais besoin de connecter 2 docker conteneurs en utilisant SSH récemment. J'ai d'abord réussi à le faire fonctionner en utilisant ssh-keyscan :

/usr/sbin/sshd
wait4ports tcp://"$1":22
if ! ssh-keygen -F "$1"; then
    ssh-keyscan "$1" > ~/.ssh/known_hosts
fi

Ensuite, w/o ssh-keyscan (en pré-générant les clés et en les injectant depuis l'hôte) :

awk -v "host=$1" '{print host, $1, $2}' \
    /etc/ssh/ssh_host_ecdsa_key.pub \
    /etc/ssh/ssh_host_ed25519_key.pub \
    /etc/ssh/ssh_host_rsa_key.pub \
    > ~/.ssh/known_hosts
/usr/sbin/sshd

Les clés de l'hôte peuvent être générées de cette façon (il y a peut-être une façon plus simple) :

docker run --rm alpine:3.15 sh -euc '
    (apk add openssh
    ssh-keygen -A
    cd /etc/ssh
    tar czf keys.tar.gz ssh_host*) >/dev/null
    cat ~/.ssh/keys.tar.gz
' > keys.tar.gz
tar xf keys.tar.gz
rm keys.tar.gz

Pour tous ceux qui se plaignent des problèmes de MITM :

Tout d'abord, si vous avez peur des attaques MITM, repensez le déploiement de votre infrastructure et la conception de votre réseau.

Mais si vous n'avez pas le choix. Cela pourrait être une solution viable :

Sur l'hôte exécutant SSHD, faites :

ssh-keygen -l -v -E sha256 -f /etc/ssh/ssh_host_ecdsa_key.pub

Sur votre hôte client SSH, faites :

ssh -o visualhostkey=yes -o FingerprintHash=sha256 myuser@my.ssh.server

Maintenant, comparez les photos, sont-elles similaires ? Félicitations tapez "oui" sur votre hôte client pour l'ajouter automatiquement à known_hosts. Sont-elles différentes ? Il peut s'agir d'une attaque MITM ou d'un simple manque de rigueur. C'est une solution acceptable si vous n'avez qu'un accès par mot de passe. Espérons que personne n'a votre mot de passe .

Mais creusons un peu plus et analysons le vrai problème ici :

Le problème est plus physique que technique. Demandez-vous ce qu'est la première couche du réseau. Pensez-y.

Voici quelques solutions viables à ce problème :

Si vous êtes dans le même lieu physique. Prenez un nouveau routeur, un commutateur et créez un réseau local qui n'est pas connecté à Internet ou à tout autre réseau inconnu. Ici, vous pouvez utiliser StrictHostKeyChecking=no autant que vous le souhaitez, sans crainte de MITM. Il en va de même pour les machines virtuelles que vous exécutez directement sur votre poste de travail dans un réseau isolé. Vous n'avez pas à vous soucier des attaques MITM si vous contrôlez la couche réseau physique.

Pensez à acheter un commutateur KVM, utilisez HPE iLO, IPMI ou même Pi-KVM si votre serveur le prend en charge. Mais même dans ce cas, ces services doivent également se trouver sur un réseau isolé. Vous pouvez également utiliser Intel-ME sur les ordinateurs portables ou les stations de travail, mais c'est une autre paire de manches.

Copiez l'empreinte de la clé de votre serveur sur une clé USB, retournez sur votre client et ajoutez manuellement l'empreinte à known_hosts à partir de la clé USB. C'est compliqué, mais vous pourrez dormir sur vos deux oreilles. Vous pouvez même automatiser quelque peu cette opération avec un script. Si vous voulez être über astucieux et impressionner le sous-fifre arrogant au-dessus de vous, automatisez cela avec "Rubber Ducky" ou autre. Mais ne soyez pas malin. L'intelligence de quelqu'un nous a amenés ici en premier lieu.

Pensez à ajouter des clés lors de l'installation de vos clients. Par exemple, sur Debian, vous pouvez utiliser Preseed et un ISO personnalisé. Il existe de nombreuses solutions.

Si vous n'avez pas accès à l'emplacement des serveurs. Appelez un ami de confiance par téléphone et demandez-lui de vérifier l'empreinte digitale avant de l'ajouter à known_hosts. Mais souvent, si vous n'avez pas d'accès physique, vous travaillez probablement pour une entreprise qui dispose déjà de solutions sécurisées pour ce genre de situation. Si ce n'est pas le cas, envisagez de changer d'emploi, ou soyez malin et proposez à votre patron une meilleure solution en échange d'une augmentation. (N'oubliez pas de mentionner le mot "Ransomware" au moins 5 fois au cours de cette conversation).

Si tout ce qui précède n'est pas une option pour vous. Et que vous voulez désespérément vous connecter à une machine inconnue quelque part sur Internet en utilisant une chaîne de proxy non cryptée. Vous devriez reconsidérer vos choix de vie. Ou vous pourriez simplement être l'homme du milieu.

J'ai été confronté à un problème similaire où, malgré l'utilisation de la solution vérifiée mentionnée ci-dessus, mon ssh ne fonctionnait pas et c'était parce que le fichier known_hosts était absent du répertoire ~/.ssh/ et le système de fichiers était en lecture seule. Donc, pendant l'exécution, je ne pouvais pas non plus créer le fichier ~/.ssh/known_hosts.

Si vous rencontrez le même problème, voyez si vous pouvez écrire le fichier known_hosts dans l'emplacement /tmp. Ce fichier est généralement accessible en écriture, même dans un système de fichiers en lecture seule.

Plus tard dans la commande ssh, vous pouvez spécifier à ssh de lire le fichier known_hosts depuis l'emplacement /tmp.

ssh -o UserKnownHostsFile=/tmp/known_hosts -o StrictHostKeyChecking=no user_name@destination_server_ip

Voici mon cas limite :

Je suis en train de créer un script fabric 2.5 pour déployer un site web sur un nouveau site. À un moment donné, il va créer une clé ssh, et ajouter la clé publique à gitlab en utilisant son api. Ensuite, il clonera un repo (contenant le code source du site web). La commande de clonage a échoué dans le script, et lorsque je suis allé sur le serveur et que j'ai lancé manuellement la commande, j'ai eu le message suivant The authenticity of host 'host.com ()' can't be established. Are you sure you want to continue connecting (yes/no)? rapide.

Au départ, ma solution était de chercher comment l'accepter automatiquement, mais pour des raisons de sécurité, j'ai ajouté l'option pty=True arg dans le c.run("command") et j'ai eu accès à l'erreur pendant l'exécution de mon script.