Kann ich known_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 diese ausführt ssh. Die virtuellen Maschinen haben zuvor nicht verwendete Hostnamen und IP-Adressen, sodass sie nicht in der ~/.ssh/known_hostsDatei auf dem zentralen Client enthalten sind.

Das Problem, das ich habe, ist, dass der erste sshBefehl, 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 Clientcomputer bereits bekannt zu machen, indem ich möglicherweise einen öffentlichen Schlüssel verwende, der bereits in das Image der virtuellen Maschine eingebrannt ist? Ich möchte wirklich vermeiden, Expect oder was auch immer verwenden zu müssen, um die interaktive Eingabeaufforderung zu beantworten, wenn ich kann.

Setzen Sie die StrictHostKeyCheckingOption noentweder in der Konfigurationsdatei oder über -o:

ssh -o StrictHostKeyChecking=no username@hostname.com

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

Dies stellt sicher, dass es keine doppelten Einträge gibt, dass Sie sowohl für den Hostnamen als auch für die IP-Adresse geschützt sind, und dass die Ausgabe als zusätzliche Sicherheitsmaßnahme gehasht wird.

Für die Faulen:

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

-H hasht den Hostnamen / die IP-Adresse

Wie bereits erwähnt, ist die Verwendung des Tastenscans die richtige und unauffällige Methode.

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

Mit dem obigen Befehl können Sie einen Host nur dann hinzufügen, wenn er noch nicht hinzugefügt wurde. Es ist auch nicht gleichzeitig sicher; Sie dürfen das Snippet nicht mehr als einmal gleichzeitig auf demselben Ursprungscomputer ausführen, da die Datei tmp_hosts verstopfen kann, was letztendlich dazu führt, dass die Datei known_hosts aufgebläht wird ...

Mit dem ssh-keyscanBefehl können Sie den öffentlichen Schlüssel abrufen und an Ihre known_hostsDatei anhängen .

So kannst du ssh-keyscan in dein 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.stdout_lines }}'

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

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

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

Es fügt den Schlüssel hinzu known_hostsund fordert nicht zur Eingabe des Kennworts auf.

Also suchte ich nach einem einfachen Weg, um die unbekannte manuelle Interaktion des Klonens eines Git-Repos zu umgehen, wie unten gezeigt:

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

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

Das ist also eine SSH-Sache, das funktioniert für Git über SSH und nur für SSH-bezogene Dinge im Allgemeinen ...

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

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, die ich ü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 aus Gründen der menschlichen Bequemlichkeit mit einem Einwegalgorithmus verkürzt wurde, wobei das Risiko besteht, dass mehr als eine Zeichenfolge in den gleichen Fingerabdruck aufgelöst wird. Es kommt vor, sie werden Kollisionen genannt.

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

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

Wir haben also vorab die Möglichkeit, den ursprünglichen Gastgeber um eine Form der Identifizierung zu bitten.

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 diese Basisdaten in Zukunft anfordern (um Kollisionen zu verhindern).

Verwenden Sie diese Zeichenfolge nun so, dass Sie nicht nach der Authentizität eines Hosts fragen müssen ...

Die Datei known_hosts verwendet in diesem Fall keine Klartexteinträge. Sie werden Hash-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.

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

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

Da ich mein Bestes getan habe, um unversehrte Daten zu erhalten, mit denen ein "Host" und eine Vertrauensstellung identifiziert werden können, füge ich diese Identifikation meiner Datei known_hosts in meinem ~ / .ssh-Verzeichnis hinzu. Da es nun als bekannter Host identifiziert wird, erhalte ich als Jugendlicher nicht die oben erwähnte Aufforderung.

Danke, dass du bei mir bleibst. Ich füge den Bitbucket-RSA-Schlüssel hinzu, damit ich dort im Rahmen eines CI-Workflows auf nicht interaktive Weise 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, die Sie angewiesen haben, den Schlüssel blind ohne Prüfung programmgesteuert hinzuzufügen. Je mehr Sie den Schlüssel von verschiedenen Computern in verschiedenen Netzwerken überprüfen, desto mehr Vertrauen können Sie in den Host haben, von dem er behauptet wird - und das ist das Beste, was Sie von dieser Sicherheitsebene erhoffen können.

FALSCH ssh -oStrictHostKeyChecking = kein Hostname [Befehl]

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

Tun Sie bitte keines der oben genannten Dinge. Sie haben die Möglichkeit, die Wahrscheinlichkeit zu erhöhen, dass nicht jemand Ihre Datenübertragungen abhört, wenn sich ein Mann in der Mitte des Angriffs befindet. Ergreifen Sie diese Gelegenheit. Der Unterschied besteht buchstäblich darin, dass der RSA-Schlüssel, über den Sie verfügen, der echte Server ist. Jetzt wissen Sie, wie Sie diese Informationen abrufen können, um sie zu vergleichen, damit Sie der Verbindung vertrauen können. Denken Sie daran, dass mehr Vergleiche von verschiedenen Computern und Netzwerken in der Regel Ihre Fähigkeit erhöhen, der Verbindung zu vertrauen.

Ich mache ein einzeiliges Skript, das ein bisschen lang, aber nützlich ist, um diese Aufgabe für Hosts mit mehreren IPs mithilfe von digund durchzuführenbash

(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

Folgendes vermeidet doppelte Einträge in ~ / .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

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-Einträge und DNSSEC in Ihrer Zone (FreeIPA bietet konfigurierbare Optionen an (DNSsec ist 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

Sobald sie veröffentlicht sind, fügen Sie VerifyHostKeyDNS yessie Ihrer ssh_config oder ~ / .ssh / config hinzu

Wenn / Wenn Google beschließt, DNSSEC zu aktivieren, können Sie ohne eine Hostkey-Eingabeaufforderung sshin.

ssh jersey.jacobdevans.com

ABER meine Domain ist noch nicht signiert, also siehst du jetzt ...

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

debug1: 4 unsichere Fingerabdrücke in DNS gefunden

debug1: passender Host-Key-Fingerprint

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

Um dies richtig zu machen, müssen Sie die öffentlichen Host-Schlüssel der VMs beim Erstellen sammeln und in einer Datei im known_hostsFormat ablegen. Anschließend können Sie mit dem -o GlobalKnownHostsFile=...Verweis auf diese Datei sicherstellen, dass Sie eine Verbindung zu dem Host herstellen, zu dem Sie eine Verbindung herstellen möchten. Wie Sie dies tun, hängt jedoch davon ab, wie Sie die virtuellen Maschinen einrichten. Möglicherweise reicht es jedoch aus, wenn Sie sie aus dem virtuellen Dateisystem auslesen oder den Host dazu bringen, den Inhalt /etc/ssh/ssh_host_rsa_key.pubwährend der Konfiguration auszudrucken .

Das lohnt sich jedoch möglicherweise nicht, je nachdem, in welcher Umgebung Sie arbeiten und wer Ihre voraussichtlichen Gegner sind. Ein einfaches "Speichern beim ersten Verbinden" (ü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. Wenn Sie dies jedoch tun, empfehle ich Ihnen dringend, die vom Benutzer bekannte Hosts-Datei ( -o UserKnownHostsFile=...) in eine Datei zu ändern, die für diese bestimmte Testinstallation spezifisch ist. Auf diese Weise wird vermieden, dass Ihre persönliche bekannte Hosts-Datei mit Testinformationen verunreinigt wird, und es wird einfacher, die jetzt unbrauchbaren öffentlichen Schlüssel zu bereinigen, wenn Sie Ihre VMs löschen.

Das ganze

• ssh-key-scan
• ssh-copy-id
• ECSDA-Schlüsselwarnung

Das Geschäft ärgerte mich immer wieder und ich entschied mich für

Ein Skript, das alle regiert

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

Beispielanruf

./sshcheck somedomain site1 site2 site3

Das Skript durchläuft die Namesites, ändert die Dateien .ssh / config und .ssh / known_hosts und führt auf Anfrage die ssh-copy-id aus. Bei der letzten Funktion können nur die ssh-Testaufrufe fehlschlagen, z. B. durch dreimaliges Drücken von die Passwortabfrage.

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

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 anschließend zwei Aufgaben, um die Schlüssel zu 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}}"

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

Wenn Sie wirklich sicher sind, dass Sie die Überprüfung des Fingerabdrucks ignorieren möchten, verwenden Sie die zweitbeste, weniger sichere Option StrictHostKeyChecking=accept-new, die in OpenSSH Version 7.6 (2017-10-03) eingeführt wurde :

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

Verwenden Sie nicht den alten Wert, StrictHostKeyChecking=noder niemals die Authentizität des Servers überprüft. (Die Bedeutung dieser =noEinstellung wird jedoch bei einigen Veröffentlichungen später umgedreht .)