it-swarm.com.de

Kann ich bekannten_Hosts automatisch einen neuen Host hinzufügen?

Hier ist meine Situation: Ich richte ein Test-Harness ein, das von einem zentralen Client aus eine Reihe von Instanzen virtueller Maschinen startet und dann Befehle über ssh auf diesen ausführt. Die virtuellen Maschinen haben zuvor nicht verwendete Hostnamen und IP-Adressen, sodass sie nicht im ~/.ssh/known_hosts Datei auf dem zentralen Client.

Das Problem, das ich habe, ist, dass der erste Befehl ssh, der für eine neue virtuelle Instanz ausgeführt wird, immer eine interaktive Eingabeaufforderung enthält:

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

Gibt es eine Möglichkeit, dies zu umgehen und den neuen Host dem Client-Computer bereits bekannt zu machen, möglicherweise mithilfe eines öffentlichen Schlüssels, der bereits in das Image der virtuellen Maschine integriert ist? Ich möchte wirklich vermeiden, Expect oder was auch immer verwenden zu müssen, um die interaktive Eingabeaufforderung zu beantworten, wenn ich kann.

265
gareth_bowles

Setzen Sie die Option StrictHostKeyChecking auf no, entweder in der Konfigurationsdatei oder über -o:

ssh -o StrictHostKeyChecking=no [email protected]

152

IMO, der beste Weg, dies zu tun, ist der folgende:

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

Dadurch wird sichergestellt, dass keine doppelten Einträge vorhanden sind, dass sowohl der Hostname als auch die IP-Adresse abgedeckt sind, und es wird auch die Ausgabe gehasht, eine zusätzliche Sicherheitsmaßnahme.

235
yardena

Für die Faulen:

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

-H hascht den Hostnamen/die IP-Adresse

97
fivef

Wie bereits erwähnt, wäre die Verwendung von Key-Scan der richtige und unauffällige Weg, dies zu tun.

ssh-keyscan -t rsa,dsa Host 2>&1 | sort -u - ~/.ssh/known_hosts > ~/.ssh/tmp_hosts
mv ~/.ssh/tmp_hosts ~/.ssh/known_hosts

Das oben Genannte führt den Trick aus, einen Host hinzuzufügen, NUR wenn er noch nicht hinzugefügt wurde. Es ist auch nicht gleichzeitig sicher. Sie dürfen nicht das Snippet mehr als einmal gleichzeitig auf demselben Origin-Computer ausführen, da die Datei tmp_hosts überlastet werden kann, was letztendlich dazu führt, dass die Datei unknown_hosts aufgebläht wird ...

44
ysawej

Sie können den Befehl ssh-keyscan Verwenden, um den öffentlichen Schlüssel abzurufen und diesen an Ihre known_hosts - Datei anzuhängen.

19
Alex

So können Sie ssh-keyscan in Ihr Spiel integrieren:

---
# 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.results | map(attribute='stdout_lines') | list }}'
8
Zart

Ich mache ein einzeiliges Skript, etwas lang, aber nützlich, um diese Aufgabe für Hosts mit mehreren IPs mit Dig und bash zu erledigen

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

dies wäre eine vollständige Lösung, bei der der Host-Schlüssel nur zum ersten Mal akzeptiert wird

#!/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([]) }}'
7
mazac

Ich hatte ein ähnliches Problem und stellte fest, dass einige der bereitgestellten Antworten mich nur teilweise zu einer automatisierten Lösung führten. Folgendes habe ich letztendlich verwendet, hoffe es hilft:

ssh -o "StrictHostKeyChecking no" -o PasswordAuthentication=no 10.x.x.x

Es fügt den Schlüssel zu known_hosts und fordert nicht zur Eingabe des Passworts auf.

6
VenomFangs

Folgende Fehler vermeiden doppelte Einträge in ~/.ssh/unknown_hosts:

if ! grep "$(ssh-keyscan github.com 2>/dev/null)" ~/.ssh/known_hosts > /dev/null; then
    ssh-keyscan github.com >> ~/.ssh/known_hosts
fi
5
Amadu Bah

Um dies richtig zu tun, möchten Sie die öffentlichen Hostschlüssel der VMs beim Erstellen sammeln und in einer Datei im Format known_hosts Ablegen. Sie können dann mit -o GlobalKnownHostsFile=... Auf diese Datei verweisen, um sicherzustellen, dass Sie eine Verbindung zu dem Host herstellen, zu dem Sie eine Verbindung herstellen sollten. Wie Sie dies tun, hängt jedoch davon ab, wie Sie die virtuellen Maschinen einrichten. Wenn möglich, können Sie dies jedoch aus dem virtuellen Dateisystem ablesen oder sogar den Host veranlassen, den Inhalt von /etc/ssh/ssh_Host_rsa_key.pub Während der Konfiguration zu drucken Trick.

Dies lohnt sich jedoch möglicherweise nicht, je nachdem, in welcher Umgebung Sie arbeiten und wer Ihre erwarteten Gegner sind. Das Ausführen eines einfachen "Speicherns bei der ersten Verbindung" (über einen Scan oder einfach während der ersten "echten" Verbindung), wie in mehreren anderen Antworten oben beschrieben, kann erheblich einfacher sein und dennoch ein gewisses Maß an Sicherheit bieten. In diesem Fall empfehle ich jedoch dringend, die vom Benutzer bekannte Hosts-Datei (-o UserKnownHostsFile=...) In eine Datei zu ändern, die für diese bestimmte Testinstallation spezifisch ist. Dadurch wird vermieden, dass Ihre persönliche bekannte Hosts-Datei mit Testinformationen verschmutzt wird, und es wird einfach, die jetzt unbrauchbaren öffentlichen Schlüssel zu bereinigen, wenn Sie Ihre VMs löschen.

5
cjs

Wie bauen Sie diese Maschinen? Können Sie ein DNS-Update-Skript ausführen? Können Sie einer IPA-Domain beitreten?

FreeIPA erledigt dies automatisch, aber im Wesentlichen benötigen Sie nur SSHFP DNS-Datensätze und DNSSSEC in Ihrer Zone (freeipa bietet als konfigurierbare Optionen (dnssec standardmäßig deaktiviert)).

Sie können die vorhandenen SSHFP-Einträge von Ihrem Host abrufen, indem Sie ausführen.

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

nach der Veröffentlichung würden Sie VerifyHostKeyDNS yes zu Ihrer ssh_config oder ~/.ssh/config

Wenn/wenn Google beschließt, DNSSEC einzuschalten, können Sie ohne Hostkey-Eingabeaufforderung ssh.

ssh jersey.jacobdevans.com

ABER meine Domain ist noch nicht signiert, also würden Sie jetzt sehen ...

debug1: Server-Host-Schlüssel: ecdsa-sha2-nistp256 SHA256: H1D3kBF9/t0ynbz2IqfUdVHhL/WROQLGan2ijkfeT0s

debug1: 4 unsichere Fingerabdrücke in DNS gefunden

debug1: Übereinstimmender Fingerabdruck des Hostschlüssels

gefunden in DNS Die Authentizität des Hosts 'jersey.jacobdevans.com (2605: 6400: 10: 434 :: 10)' kann nicht festgestellt werden. Der ECDSA-Schlüsselfingerabdruck lautet SHA256: H1D3kBF9/t0ynbz2IqfUdVHhL/WROQLGan2ijkfeT0s. Passender Fingerabdruck des Hostschlüssels im DNS gefunden. Sind Sie sicher, dass Sie die Verbindung fortsetzen möchten (Ja/Nein)? Nein

5
Jacob Evans

Das ganze

  • sSH-Key-Scan
  • ssh-copy-id
  • ECSDA-Schlüsselwarnung

das Geschäft nervte mich immer wieder, also entschied ich mich für

Ein Skript, um alle zu regieren

Dies ist eine Variante des Skripts unter https://askubuntu.com/a/949731/129227 mit Amadu Bahs Antwort https://serverfault.com/a/858957/16269 in einer Schleife.

Beispielaufruf

./sshcheck somedomain site1 site2 site3

Das Skript durchläuft die Namensseiten und ändert die Dateien .ssh/config und .ssh/unknown_hosts und führt auf Anfrage eine ssh-copy-id aus - für die letzte Funktion nur, damit die ssh-Testaufrufe fehlschlagen, z. durch dreimaliges Drücken der Eingabetaste bei der Passwortanfrage.

sshcheck script

#!/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
4
Wolfgang Fahl

Also suchte ich nach einer alltäglichen Möglichkeit, die unbekannte manuelle Host-Interaktion des Klonens eines Git-Repos zu umgehen, wie unten gezeigt:

[email protected]:~$ 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)?

Beachten Sie den Fingerabdruck des RSA-Schlüssels ...

Also, das ist eine SSH-Sache, das wird für Git über SSH funktionieren und nur für SSH-bezogene Dinge im Allgemeinen ...

[email protected]:~$ 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

Installieren Sie zunächst nmap auf Ihrem täglichen Treiber. nmap ist sehr hilfreich für bestimmte Dinge, wie das Erkennen offener Ports und das manuelle Überprüfen von SSH-Fingerabdrücken. Aber zurück zu dem, was wir tun.

Gut. Entweder bin ich an den verschiedenen Stellen und Maschinen, an denen ich es überprüft habe, kompromittiert - oder die plausibelere Erklärung dafür, dass alles gut gelaunt ist, ist das, was passiert.

Dieser 'Fingerabdruck' ist nur eine Zeichenfolge, die mit einem Einwegalgorithmus für unsere menschliche Bequemlichkeit verkürzt wurde, wobei das Risiko besteht, dass mehr als eine Zeichenfolge in denselben Fingerabdruck aufgelöst wird. Es kommt vor, sie werden Kollisionen genannt.

Unabhängig davon, zurück zur ursprünglichen Zeichenfolge, die wir im folgenden Kontext sehen können.

[email protected]:~$ 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

Wir haben also die Möglichkeit, im Voraus eine Form der Identifizierung beim ursprünglichen Host anzufordern.

Zu diesem Zeitpunkt sind wir manuell genauso anfällig wie automatisch - die Zeichenfolgen stimmen überein, wir haben die Basisdaten, die den Fingerabdruck erstellen, und wir könnten in Zukunft nach diesen Basisdaten fragen (um Kollisionen zu verhindern).

Verwenden Sie diese Zeichenfolge jetzt so, dass Sie nicht nach der Authentizität eines Hosts gefragt werden müssen ...

Die Datei unknown_hosts verwendet in diesem Fall keine Klartexteinträge. Sie werden gehashte Einträge kennen, wenn Sie sie sehen. Sie sehen aus wie Hashes mit zufälligen Zeichen anstelle von xyz.com oder 123.45.67.89.

[email protected]:~$ 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==

Die erste Kommentarzeile wird ärgerlich angezeigt - aber Sie können sie mit einer einfachen Weiterleitung über die Konvention ">" oder ">>" entfernen.

Da ich mein Bestes getan habe, um unbefleckte Daten zu erhalten, die zur Identifizierung eines "Hosts" und eines Vertrauens verwendet werden können, werde ich diese Identifikation zu meiner Datei "unknown_hosts" in meinem Verzeichnis ~/.ssh hinzufügen. Da es jetzt als bekannter Host identifiziert wird, werde ich die oben erwähnte Eingabeaufforderung nicht erhalten, als Sie ein Jugendlicher waren.

Danke, dass du bei mir bleibst, los geht's. Ich füge den Bitbucket-RSA-Schlüssel hinzu, damit ich dort im Rahmen eines CI-Workflows nicht interaktiv mit meinen Git-Repositorys interagieren kann, aber was auch immer Sie tun, was Sie wollen.

#!/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

So bleibst du heute Jungfrau. Sie können dasselbe mit Github tun, indem Sie in Ihrer Freizeit ähnlichen Anweisungen folgen.

Ich habe so viele Stapelüberlaufpfosten gesehen, in denen Sie aufgefordert wurden, den Schlüssel programmgesteuert blind hinzuzufügen, ohne ihn zu überprüfen. Je mehr Sie den Schlüssel von verschiedenen Computern in verschiedenen Netzwerken überprüfen, desto mehr Vertrauen können Sie haben, dass der Host derjenige ist, von dem er sagt, dass er es ist - und das ist das Beste, was Sie von dieser Sicherheitsebene hoffen können.

FALSCH ssh -oStrictHostKeyChecking = kein Hostname [Befehl]

FALSCH ssh-keyscan -t rsa -H Hostname >> ~/.ssh/unknown_hosts

Tun Sie bitte keines der oben genannten Dinge. Sie haben die Möglichkeit, Ihre Chancen zu erhöhen, zu vermeiden, dass jemand Ihre Datenübertragungen über einen Mann im mittleren Angriff belauscht - nutzen Sie diese Gelegenheit. Der Unterschied besteht buchstäblich darin, zu überprüfen, ob der RSA-Schlüssel, den Sie haben, der des echten Servers ist, und jetzt wissen Sie, wie Sie diese Informationen zum Vergleichen erhalten, damit Sie der Verbindung vertrauen können. Denken Sie daran, dass mehr Vergleiche von verschiedenen Computern und Netzwerken normalerweise Ihre Fähigkeit verbessern, der Verbindung zu vertrauen.

4
BradChesney79

Überprüfen Sie den Fingerabdruck jedes neuen Servers/Hosts. Dies ist die einzige Möglichkeit, den Server zu authentifizieren. Ohne sie kann Ihre SSH-Verbindung einem Man-in-the-Middle-Angriff ausgesetzt sein.

Verwenden Sie nicht den alten Wert StrictHostKeyChecking=no which never überprüft überhaupt die Authentizität des Servers. Obwohl das Bedeutung von StrictHostKeyChecking=no wird später umgedreht .

Die zweite, aber weniger sichere Option ist die Verwendung von StrictHostKeyChecking=accept-new, das war eingeführt in Version 7.6 (2017-10-03) von OpenSSH :

Das erste "Akzeptieren-Neu" akzeptiert automatisch bisher nicht sichtbare Schlüssel, lehnt jedoch Verbindungen für geänderte oder ungültige Hostschlüssel ab.

2
Dominik

Hier erfahren Sie, wie Sie eine Sammlung von Hosts erstellen

definieren Sie eine Sammlung von Hosts

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

Definieren Sie dann zwei Aufgaben, um die Schlüssel bekannten Hosts hinzuzufügen:

- 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}}"
2
Vackar Afzal

Wenn Sie den Schlüssel überprüfen möchten, bevor Sie ihn blind hinzufügen, können Sie diesen Code verwenden:

# verify github and gitlab key
# GitHub
github=SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8
ssh-keyscan github.com >> githubKey
read bit githubkey Host <<< $(ssh-keygen -lf githubKey)
if [ "$githubkey" != "$github" ]
then
  echo "The GitHub fingerprint is incorrect"
  exit 1
fi
echo "github.com ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==" | Sudo tee -a /etc/ssh/ssh_known_hosts

# GitLab
gitlab=SHA256:ROQFvPThGrW4RuWLoL9tq9I9zJ42fK4XywyRtbOz/EQ
ssh-keyscan gitlab.com >> gitlabKey
read bit gitlabkey Host <<< $(ssh-keygen -lf gitlabKey)
if [ "$githubkey" != "$github" ]
then
  echo "The GitLab fingerprint is incorrect"
  exit 1
fi
echo "gitlab.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCsj2bNKTBSpIYDEGk9KxsGh3mySTRgMtXL583qmBpzeQ+jqCMRgBqB98u3z++J1sKlXHWfM9dyhSevkMwSbhoR8XIq/U0tCNyokEi/ueaBMCvbcTHhO7FcwzY92WK4Yt0aGROY5qX2UKSeOvuP4D6TPqKF1onrSzH9bx9XUf2lEdWT/ia1NEKjunUqu1xOB/StKDHMoX4/OKyIzuS0q/T1zOATthvasJFoPrAjkohTyaDUz2LN5JoH839hViyEG82yB+MjcFV5MU3N1l1QL3cVUCh93xSaua1N85qivl+siMkPGbO5xR/En4iEY6K2XPASUEMaieWVNTRCtJ4S8H+9" | Sudo tee -a /etc/ssh/ssh_known_hosts

Die GitHub- und GitLab-Schlüssel können sich ändern, wenn sie kompromittiert werden. Überprüfen Sie in diesem Fall die neuesten hier und dort

Anmerkung : Möglicherweise müssen Sie sicherstellen, dass der Schlüssel nicht zweimal hinzugefügt wird. Weitere Informationen hierzu finden Sie in anderen Antworten.

1
Sharcoux

Ich hatte ein ähnliches Problem, bei dem mein SSH trotz Verwendung der oben genannten verifizierten Lösung nicht funktionierte und weil die Datei unknown_hosts im Verzeichnis ~/.ssh/fehlte und das Dateisystem schreibgeschützt war. SO zur Laufzeit konnte ich auch die Datei ~/.ssh/unknown_hosts nicht erstellen.

Wenn Sie mit einem ähnlichen Problem konfrontiert sind, prüfen Sie, ob Sie die Datei unknown_hosts am Speicherort/tmp schreiben können. Dies ist meistens schreibgeschützt, selbst in einem schreibgeschützten Dateisystem.

Später im Befehl ssh können Sie den ssh angeben, der die Datei unknown_hosts vom Speicherort/tmp lesen soll.

ssh -o UserKnownHostsFile =/tmp/bekannte_hosts -o StrictHostKeyChecking = kein Benutzername @ Zielserver_ip

0
Rohit Agrawal