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

249

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 via celles-ci ssh. Les ordinateurs virtuels auront des noms d’hôte et des adresses IP inutilisés, ils ne figureront donc pas dans le ~/.ssh/known_hostsfichier sur le client central.

Le problème que je rencontre est que la première sshcommande 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 de faire en sorte 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.

gareth_bowles
la source
5
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 fiable (tel qu'Internet) contourne complètement toute protection contre les attaques interceptées que SSH se permettrait autrement. Le seul moyen 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:

142

Définissez l' StrictHostKeyCheckingoption sur no, soit dans le fichier de configuration, soit via -o:

ssh -o StrictHostKeyChecking=no [email protected]

Ignacio Vazquez-Abrams
la source
62
Cela vous laisse ouvert à l'homme au milieu des attaques, probablement pas une bonne idée.
JasperWallace
9
@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ûr.
Massimo
8
Cela donne une 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 à aucun fichier known_hosts, je fais:ssh -o StrictHostKeyChecking=no -o LogLevel=ERROR -o UserKnownHostsFile=/dev/null [email protected]
Peter V. Mørch
11
Le vote préférentiel, car cela ne répond pas à la question et ouvre de graves vulnérabilités en matière de sécurité.
Marcv81
12
@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
230

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.

yardena
la source
4
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
6
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
2
@JasperWallace Oui, pour cela, vous avez besoin d'au moins l'empreinte digitale ou, mieux encore, de la clé publique. Dans ce cas, vous pouvez l'ajouter directement à known_hosts, rendant cette question sans objet. Si vous ne disposez que de l’empreinte digitale, vous devrez écrire une étape supplémentaire permettant de vérifier la clé publique téléchargée avec votre empreinte digitale ...
1
Les 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. L'ajout -t rsa,dsaà la commande a résolu ce problème.
phasetwenty
5
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]. medium.com/@wblankenship/…
retrohacker le
93

Pour les paresseux:

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

-H hache le nom d'hôte / adresse IP

cinq
la source
2
"ssh-keyscan -H <hôte> >> ~ / .ssh / known_hosts" produit une entrée plus proche de ce que ssh fait avec l'interaction utilisateur. (Le -H hache le nom de l'hôte distant.)
Sarah Messer
3
Vulnérable aux attaques MITM. Vous ne vérifiez pas l'empreinte digitale de la clé.
Mnebuerquo
8
@Mnebuerquo Vous dites quoi faire mais pas comment, ce qui serait utile.
Ray
4
@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
2
@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
42

Comme mentionné précédemment, l'utilisation de la numérisation au clavier serait le moyen le plus approprié et le plus discret de le faire.

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 devez pas exécuter l'extrait de code sur le même ordinateur d'origine plus d'une fois à la fois, car le fichier tmp_hosts peut être obstrué, ce qui finit par entraîner un gonflement du fichier known_hosts ...

Ysawej
la source
Y at - il un moyen de vérifier si la clé est dans known_hosts avant ssh-keyscan ? La raison en est que cela nécessite du temps et une connexion réseau supplémentaire.
utapyngo
1
La version de ce fichier de l’affiche originale était disponible cat ~/.ssh/tmp_hosts > ~/.ssh/known_hosts, mais une modification ultérieure l’a remplacé >>. L'utilisation >>est une erreur. Cela va à l'encontre du but de l'unicité dans la première ligne et l'oblige à ajouter de nouvelles entrées known_hostschaque fois qu'il s'exécute. (Nous venons de poster une modification pour la rétablir.)
paulmelnikow
1
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
1
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
19

Vous pouvez utiliser la ssh-keyscancommande pour récupérer la clé publique et l'ajouter à votre known_hostsfichier.

Alex
la source
3
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
3
@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
8

Voici comment intégrer ssh-keyscan à 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 }}'
Zart
la source
1
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
1
Ceci est simplement une sortie de la sortie d'un keyscan, oui. En pratique, cela revient à StrictHostKeyChecking = no, juste avec la mise à jour silencieuse de known_hosts sans modifier les options ssh. Cette solution ne fonctionne pas non plus correctement car ssh-keys peut renvoyer plusieurs lignes, ce qui a pour effet que cette tâche soit toujours marquée comme "modifiée"
16h16
Ce n'est pas la façon de le faire. MITM.
jameshfisher
3
@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
C'est une méthode parfaitement valide pour ajouter des valeurs à known_hosts, mais oui, elle est sensible à MITM. Cependant, pour un usage interne, c'est très bien.
Cameron Lowell Palmer
7

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([]) }}'
Mazac
la source
1
Ce n'est pas la façon de le faire. MITM.
jameshfisher
6

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_hostset ne demande pas le mot de passe.

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

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

brad@computer:~$ git clone [email protected]: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, comme la détection des ports ouverts et 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 est dingue 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 un 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, utilisez cette chaîne de manière à ne pas poser de 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 saurez que 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.

BradChesney79
la source
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ée 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 utiliseriez un ordinateur local non soumis aux restrictions d'analyse du port AWS. Mais, si vous vous trouvez 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
1
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). Ils diront toujours oui, mais si vous demandez à la mauvaise personne, cela n'a pas d'importance.
vastlysuperiorman
5

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

(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
Felipe Alcacibar
la source
5

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
Amadu Bah
la source
1
Ce n'est pas la façon de le faire. MITM.
jameshfisher
J'aime mieux cette réponse. Pour le script d'installation initiale d'un VPS aléatoire sans importance pour personne d'autre que moi, le risque MITM est extrêmement faible. Quibbles Infinitésimal ... première ligne doit êtremkdir -p ~/.ssh/known_hosts;
Martin Bramwell
5

Comment construisez-vous ces machines? pouvez-vous exécuter un script de mise à jour DNS? pouvez-vous rejoindre un domaine IPA?

FreeIPA le fait automatiquement, mais vous avez essentiellement besoin d’ enregistrements DNS SSHFP et de DNSSEC sur votre zone (freeipa fournit des options configurables (dnssec désactivé par défaut)).

Vous pouvez obtenir les enregistrements SSHFP existants auprès de votre hôte en les exécutant.

ssh-keygen -r jersey.jacobdevans.com

jersey.jacobdevans.com IN SSHFP 1 1 4d8589de6b1a48e148d8fc9fbb967f1b29f53ebc jersey.jacobdevans.com IN SSHFP 1 2 6503272a11ba6d7fec2518c02dfed88f3d455ac7786ee5dbd72df63307209d55 jersey.jacobdevans.com IN SSHFP 3 1 5a7a1e8ab8f25b86b63c377b303659289b895736> jersey.jacobdevans.com IN SSHFP 3 2 1f50f790117dfedd329dbcf622a7d47551e12ff5913902c66a7da28e47de4f4b

puis une fois publié, vous ajouteriez VerifyHostKeyDNS yesà votre ssh_config ou ~ / .ssh / config

Si / Quand google décide de basculer sur DNSSEC, vous pouvez entrer sans inviter la clé d’accueil.

ssh jersey.jacobdevans.com

MAIS mon domaine n’est pas encore signé, alors pour le moment, vous verriez ...

debug1: clé d'hôte du serveur: ecdsa-sha2-nistp256 SHA256: H1D3kBF9 / t0ynbz2IqfUdVHhL / WROQLGan2ijkfeT0s

debug1: 4 empreintes digitales non sécurisées trouvées dans DNS

debug1: empreinte de la clé d'hôte correspondante

trouvé dans le DNS L'authenticité de l'hôte 'jersey.jacobdevans.com (2605: 6400: 10: 434 :: 10)' ne peut pas être établie. L’empreinte de la clé ECDSA est SHA256: H1D3kBF9 / t0ynbz2IqfUdVHhL / WROQLGan2ijkfeT0s. Empreinte digitale de clé d'hôte correspondante trouvée dans le DNS. Êtes-vous sûr de vouloir continuer à vous connecter (oui / non)? non

Jacob Evans
la source
4

Pour le faire correctement, vous voulez vraiment collecter les clés publiques de l'hôte des ordinateurs virtuels lors de leur création et les déposer dans un fichier au known_hostsformat. Vous pouvez ensuite utiliser la -o GlobalKnownHostsFile=...touche pointant vers ce fichier pour vous assurer que vous vous connectez à l'hôte auquel vous croyez que vous devriez vous connecter. Cela dépend toutefois de la manière dont vous configurez les machines virtuelles, mais le lire sur le système de fichiers virtuel, si possible, ou même demander à l'hôte d'imprimer le contenu /etc/ssh/ssh_host_rsa_key.pubpendant la configuration peut faire l'affaire.

Cela dit, cela n’en vaut peut-être pas la peine, selon le type d’environnement dans lequel vous travaillez et les adversaires que vous envisagez. Effectuer un simple "stockage lors de la première connexion" (via une analyse ou tout simplement lors de la première "connexion" réelle) comme décrit dans plusieurs autres réponses ci-dessus peut être considérablement plus simple et fournir néanmoins un minimum de sécurité. Cependant, si vous faites cela, je vous suggère fortement de changer le fichier hosts ( -o UserKnownHostsFile=...) connu de l'utilisateur en un fichier spécifique pour cette installation de test particulière; Cela évitera de polluer votre fichier hôte connu personnel avec des informations de test et facilitera le nettoyage des clés publiques désormais inutiles lorsque vous supprimez vos ordinateurs virtuels.

Curt J. Sampson
la source
4

Ce tout

  • ssh-key-scan
  • ssh-copy-id
  • Avertissement de clé ECSDA

les affaires continuaient à m'agacer alors j'ai opté pour

Un script pour les gouverner tous

Ceci est une variante du script à l' adresse https://askubuntu.com/a/949731/129227 avec la réponse d'Amadu Bah https://serverfault.com/a/858957/162693 .

exemple d'appel

./sshcheck somedomain site1 site2 site3

Le script parcourt les noms de sites et modifie les fichiers .ssh / config et .ssh / known_hosts et effectue ssh-copy-id sur requête - pour la dernière fonctionnalité, l'échec des appels de test ssh la demande de mot de passe.

script sshcheck

#!/bin/bash
# WF 2017-08-25
# check ssh access to bitplan servers

#ansi colors
#http://www.csc.uvic.ca/~sae/seng265/fall04/tips/s265s047-tips/bash-using-colors.html
blue='\033[0;34m'  
red='\033[0;31m'  
green='\033[0;32m' # '\e[1;32m' is too bright for white bg.
endColor='\033[0m'

#
# a colored message 
#   params:
#     1: l_color - the color of the message
#     2: l_msg - the message to display
#
color_msg() {
  local l_color="$1"
  local l_msg="$2"
  echo -e "${l_color}$l_msg${endColor}"
}

#
# error
#
#   show an error message and exit
#
#   params:
#     1: l_msg - the message to display
error() {
  local l_msg="$1"
  # use ansi red for error
  color_msg $red "Error: $l_msg" 1>&2
  exit 1
}

#
# show the usage
#
usage() {
  echo "usage: $0 domain sites"
  exit 1 
}

#
# check known_hosts entry for server
#
checkknown() {
  local l_server="$1"
  #echo $l_server
  local l_sid="$(ssh-keyscan $l_server 2>/dev/null)" 
  #echo $l_sid
  if (! grep "$l_sid" $sknown) > /dev/null 
  then
    color_msg $blue "adding $l_server to $sknown"
    ssh-keyscan $l_server >> $sknown 2>&1
  fi
}

#
# check the given server
#
checkserver() {
  local l_server="$1"
  grep $l_server $sconfig > /dev/null
  if [ $? -eq 1 ]
  then
    color_msg $blue "adding $l_server to $sconfig"
    today=$(date "+%Y-%m-%d")
    echo "# added $today by $0"  >> $sconfig
    echo "Host $l_server" >> $sconfig
    echo "   StrictHostKeyChecking no" >> $sconfig
    echo "   userKnownHostsFile=/dev/null" >> $sconfig
    echo "" >> $sconfig
    checkknown $l_server
  else
    color_msg $green "$l_server found in $sconfig"
  fi
  ssh -q $l_server id > /dev/null
  if [ $? -eq 0 ]
  then
    color_msg $green "$l_server accessible via ssh"
  else
    color_msg $red "ssh to $l_server failed" 
    color_msg $blue "shall I ssh-copy-id credentials to $l_server?"
    read answer
    case $answer in
      y|yes) ssh-copy-id $l_server
    esac
  fi
}

#
# check all servers
#
checkservers() {
me=$(hostname -f)
for server in $(echo $* | sort)
do
  os=`uname`
  case $os in
   # Mac OS X
   Darwin*)
     pingoption=" -t1";;
    *) ;;
  esac

  pingresult=$(ping $pingoption -i0.2 -c1 $server)
  echo $pingresult | grep 100 > /dev/null
  if [ $? -eq 1 ]
  then 
    checkserver $server
    checkserver $server.$domain
  else
    color_msg $red "ping to $server failed"
  fi
done
}

#
# check configuration
#
checkconfig() {
#https://askubuntu.com/questions/87449/how-to-disable-strict-host-key-checking-in-ssh
  if [ -f $sconfig ]
  then
    color_msg $green "$sconfig exists"
    ls -l $sconfig
  fi
}

sconfig=~/.ssh/config
sknown=~/.ssh/known_hosts

case  $# in
  0) usage ;;
  1) usage ;;
  *) 
    domain=$1 
    shift 
    color_msg $blue "checking ssh configuration for domain $domain sites $*"
    checkconfig
    checkservers $* 
    #for server in $(echo $* | sort)
    ##do
    #  checkknown $server 
    #done
    ;;
esac
Wolfgang Fahl
la source
2

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

Ensuite, définissez 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}}"
Vackar Afzal
la source
0

Le mieux serait de vérifier l'empreinte de chaque nouveau serveur / hôte. C'est le seul moyen d'authentifier le serveur. Sans cela, votre connexion SSH peut être sujette à une attaque de type " man-in-the-middle" .

Si vous êtes vraiment sûr de vouloir ignorer la vérification de l'empreinte digitale, la deuxième meilleure option, moins sécurisée, consiste à utiliser StrictHostKeyChecking=accept-new, qui a été introduite dans OpenSSH version 7.6 (2017-10-03) :

Le premier "accept-new" acceptera automatiquement les clés inédites, mais refusera les connexions pour les clés hôtes modifiées ou non valides.

N'utilisez pas l'ancienne valeur, StrictHostKeyChecking=noqui ne vérifie jamais l'authenticité du serveur. (Bien que la signification de ce =noparamètre soit inversée certaines versions plus tard .)

Dominik
la source