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

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.

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

ssh -o StrictHostKeyChecking=no [email protected]

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.

Pour les paresseux:

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

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

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 ...

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

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 }}'

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

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.

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.

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

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

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

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.

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

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}}"

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 .)