Kann ich known_hosts automatisch einen neuen Host hinzufügen?


249

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.


5
In einer Testumgebung, die in sich abgeschlossen und physisch sicher ist, funktioniert die automatische Schlüsselübernahme möglicherweise einwandfrei. Das automatische Akzeptieren öffentlicher Schlüssel in einer Produktionsumgebung oder in einem nicht vertrauenswürdigen Netzwerk (wie dem Internet) umgeht jedoch vollständig den Schutz vor Man-in-the-Middle-Angriffen, den SSH sonst leisten würde. Die einzig gültige Methode, um sicherzustellen, dass Sie gegen MITM-Angriffe geschützt sind, besteht darin, den öffentlichen Schlüssel des Hosts über einen vertrauenswürdigen Out-of-Band-Kanal zu überprüfen. Es gibt keine sichere Möglichkeit zur Automatisierung, ohne eine mäßig komplizierte Schlüssel-Signatur-Infrastruktur einzurichten.
Eil

Antworten:


141

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

ssh -o StrictHostKeyChecking=no username@hostname.com


62
Dies lässt Sie offen für Angriffe in der Mitte, wahrscheinlich keine gute Idee.
JasperWallace

9
@JasperWallace, obwohl dies normalerweise ein guter Rat ist, sollte der spezifische Anwendungsfall (Bereitstellen von Test-VMs und Senden von Befehlen an sie) sicher genug sein.
Massimo

8
Dies gibt eine Warning: Permanently added 'hostname,1.2.3.4' (RSA) to the list of known hosts.Um die Warnung zu vermeiden und um zu verhindern, dass der Eintrag zu einer bekannten_Hosts-Datei hinzugefügt wird, mache ich Folgendes:ssh -o StrictHostKeyChecking=no -o LogLevel=ERROR -o UserKnownHostsFile=/dev/null username@hostname.com
Peter V. Mørch

11
Downvoting, da dies die Frage nicht beantwortet und zu schwerwiegenden Sicherheitslücken führt.
Marcv81

12
@Mnebuerquo: Wenn Sie sich um die Sicherheit Sorgen machen würden, hätten Sie mit dieser Frage überhaupt nichts zu tun. Sie hätten den richtigen Host-Schlüssel vor sich, der von der Konsole des Systems stammt, zu dem Sie eine Verbindung herstellen möchten, und Sie würden ihn beim ersten Herstellen der Verbindung manuell überprüfen. Sie würden mit Sicherheit nichts "automatisch" machen.
Ignacio Vazquez-Abrams

230

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.


4
Warum brauchst du alle 3 ssh-keyscans? Kommst du mit dem ersten nicht klar, da es sowohl für den Hostnamen als auch für die IP-Adresse funktioniert?
Robert

6
Können Sie sicher sein, dass der Computer, der auf die ssh-keyscan-Anfrage antwortet, wirklich derjenige ist, mit dem Sie sprechen möchten? Wenn nicht, haben Sie sich einem Mann in der Mitte des Angriffs geöffnet.
JasperWallace

2
@JasperWallace Ja, dafür benötigen Sie mindestens den Fingerabdruck oder noch besser den öffentlichen Schlüssel. In diesem Fall können Sie ihn direkt zu known_hosts hinzufügen und so diese Frage zur Diskussion stellen. Wenn Sie nur den Fingerabdruck haben, müssen Sie einen zusätzlichen Schritt schreiben, der den heruntergeladenen öffentlichen Schlüssel mit Ihrem Fingerabdruck überprüft ...

1
Anrufe an ssh-keyscanscheiterten, weil mein Zielhost den Standardschlüsseltyp der Version 1 nicht unterstützt. Das Hinzufügen -t rsa,dsazum Befehl behebt dies.
Phasetwenty

5
Das ist wahrscheinlich eine schlechte Idee. Sie öffnen sich einem Man-in-the-Middle-Angriff, indem Sie diese Schlüssel aktualisieren. Um doppelte Einträge zu vermeiden, überprüfen Sie ssh-keygen -F [address]stattdessen den Rückgabestatus von . medium.com/@wblankenship/…
retrohacker

93

Für die Faulen:

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

-H hasht den Hostnamen / die IP-Adresse


2
"ssh-keyscan -H <host> >> ~ / .ssh / known_hosts" erzeugt einen Eintrag, der eher dem entspricht, was ssh bei der Benutzerinteraktion tut. (Das -H hasht den Namen des Remote-Hosts.)
Sarah Messer

3
Anfällig für MITM-Angriffe. Sie überprüfen nicht den Schlüsselfingerabdruck.
Mnebuerquo

8
@Mnebuerquo Du sagst was zu tun ist aber nicht wie, was hilfreich wäre.
Ray

4
@jameshfisher Ja, es ist anfällig für MITM-Angriffe, aber haben Sie jemals den RSA-Fingerabdruck, der Ihnen angezeigt wurde, mit dem tatsächlichen des Servers verglichen, als Sie dies manuell machten? Nein? Diese Antwort ist der Weg, dies für Sie zu tun. Wenn ja, sollten Sie diese Antwort nicht manuell verwenden oder andere Sicherheitsmaßnahmen ergreifen ...
5.

2
@Mnebuerquo Ich würde mich sehr freuen, wenn Sie uns auch mitteilen, wie wir dies besser handhaben können, wenn wir ein Repo mit nicht besetzten Batch-Skripten klonen müssen und diese Aufforderung umgehen möchten. Bitte werfen Sie etwas Licht auf eine echte Lösung, wenn Sie denken, dass dies nicht die richtige ist!
Waqas Shah

42

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


Gibt es eine Möglichkeit zu überprüfen , ob der Schlüssel in known_hosts vor ssh-keyscan ? Der Grund ist, dass es einige Zeit und zusätzliche Netzwerkverbindung erfordert.
Utapyngo

1
Die ursprüngliche Posterversion dieser Datei hatte cat ~/.ssh/tmp_hosts > ~/.ssh/known_hosts, aber eine nachfolgende Bearbeitung änderte sie in >>. Verwenden >>ist ein Fehler. Es überwindet den Zweck der Eindeutigkeit in der ersten Zeile und bewirkt, dass bei known_hostsjeder Ausführung neue Einträge abgelegt werden. (
Habe

1
Dies unterliegt den gleichen MITM-Angriffen wie die anderen.
Mnebuerquo

@utapyngo ssh-keygen -F gibt Ihnen den aktuellen Fingerabdruck. Wenn es mit dem Rückkehrcode 1 leer zurückkommt, haben Sie es nicht. Wenn etwas gedruckt wird und der Rückkehrcode 0 ist, ist er bereits vorhanden.
Rich L

1
Wenn Sie sich so sehr für MITM interessieren, stellen Sie DNSSEC- und SSHFP-Datensätze bereit oder verwenden Sie eine andere sichere Methode zum Verteilen der Schlüssel. Diese Kludge-Lösung ist dann irrelevant.
Zart

19

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


3
Stellen Sie sicher, dass Sie den Fingerabdruck überprüfen, um sicherzustellen, dass es sich um den richtigen Schlüssel handelt. Ansonsten öffnen Sie sich für MITM-Angriffe.
Mnebuerquo

3
@Mnebuerquo Guter Punkt im allgemeinen Kontext, aber warum sollte jemand versuchen, programmgesteuert Schlüssel zu sammeln, wenn er bereits wusste, welcher der richtige Schlüssel ist?
Brian Cline

Dies ist nicht der richtige Weg. MITM.
Jameshfisher

8

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

1
Laden Sie eine bekanntermaßen gültige Datei "known_hosts" hoch oder führen Sie "ssh-keyscan" durch und speichern die Ausgabe in "known_hosts", ohne die Fingerabdrücke zu überprüfen?
Mnebuerquo

1
Das ist einfach die Ausgabe eines Keyscans, ja. Tatsächlich ist es also dasselbe wie StrictHostKeyChecking = no, nur mit stillen Aktualisierungen von known_hosts, ohne mit ssh-Optionen herumzuspielen. Diese Lösung funktioniert auch nicht gut, da ssh-keyscan mehrere Zeilen zurückgibt, wodurch diese Aufgabe immer als "geändert" gekennzeichnet wird
Zart

Dies ist nicht der richtige Weg. MITM.
Jameshfisher

3
@jameshfisher Ich würde mich sehr freuen, wenn Sie uns auch mitteilen, wie wir dies besser handhaben können, wenn wir ein Repo mit nicht besetzten Batch-Skripten klonen müssen und diese Aufforderung umgehen möchten. Bitte werfen Sie etwas Licht auf eine echte Lösung, wenn Sie denken, dass dies nicht die richtige ist! Bitte lassen Sie uns wissen, wie es geht, wenn Sie der Meinung sind, dass dies nicht der richtige Weg ist!
Waqas Shah

Es ist eine absolut gültige Methode zum Hinzufügen von Werten zu known_hosts, aber es ist anfällig für MITM. Für den internen Gebrauch ist es jedoch in Ordnung.
Cameron Lowell Palmer

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

1
Dies ist nicht der richtige Weg. MITM.
Jameshfisher

6

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.


2
Anfällig für MITM-Angriffe. Sie überprüfen nicht den Fingerabdruck.
Mnebuerquo

6
Niemand überprüft den Fingerabdruck.
Brendan Byrd

Dies ist nicht der richtige Weg. MITM.
Jameshfisher

5

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 denke, das ist die beste Lösung für dieses Problem. Seien Sie jedoch sehr vorsichtig, wenn Sie Nmap auf so etwas wie Amazon EC2 verwenden. Ich habe eine Warnung bezüglich des Port-Scans erhalten, den Nmap ausführt! Füllen Sie das Formular aus, bevor Sie mit dem Scannen beginnen!
Waqas Shah

...Gut ja. Ich weiß nicht, warum Sie den Port-Scan von EC2 durchführen würden. Wenn Sie in Ihrem Konto angemeldet sind, können Sie nur die Schlüssel von den tatsächlichen Maschinen erhalten. Dies gilt eher für Maschinen, über die Sie keine Kontrolle haben. Ich gehe davon aus, dass Sie einen lokalen Computer haben, auf dem keine Einschränkungen für die AWS-Port-Überprüfung gelten. Wenn Sie sich jedoch in einer Randsituation befinden, in der Sie nmap mit AWS ausführen müssen, ist diese Warnung wahrscheinlich hilfreich.
BradChesney79

Die Verwendung von nmap zum Lesen des SSH-Hostschlüssels von Ihrer Workstation und das anschließende Vertrauen in diesen Wert unterscheidet sich nicht von der Verbindung über SSH, wenn StructHostKeyChecking deaktiviert ist. Es ist genauso anfällig für einen Man-in-the-Middle-Angriff.
Micah R Ledbetter

... @ MicahRLedbetter, aus diesem Grund schlug ich vor, dass "mehr Vergleiche von verschiedenen Computern und Netzwerken normalerweise Ihre Fähigkeit erhöhen, der Verbindung zu vertrauen". Aber das ist mein Punkt. Wenn Sie Ihren Zielhost nur anhand einer Reihe von Umgebungsbedingungen überprüfen, wie würden Sie dann jemals Unstimmigkeiten feststellen? Hattest du bessere Vorschläge?
BradChesney79

1
Das ist Sicherheitstheater. Etwas Kompliziertes tun, um den Anschein größerer Sicherheit zu erwecken. Es spielt keine Rolle, wie viele verschiedene Methoden Sie verwenden, um den Host nach seinem Schlüssel zu fragen. Fragen Sie beispielsweise dieselbe Person mehrmals, ob Sie ihr vertrauen können (vielleicht rufen Sie an, senden eine E-Mail, eine SMS oder eine Schneckenpost). Sie werden immer Ja sagen, aber wenn Sie die falsche Person fragen, spielt es keine Rolle.
Riesen Superiorman

5

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

5

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

1
Dies ist nicht der richtige Weg. MITM.
Jameshfisher

Diese Antwort gefällt mir am besten. Für die Skripterstellung einer zufälligen VPS, die für niemanden außer mich von Bedeutung ist, ist das MITM-Risiko äußerst gering. Infinitesimaler Streit ... die erste Zeile muss lautenmkdir -p ~/.ssh/known_hosts;
Martin Bramwell

5

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


4

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.


4

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

2

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

0

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

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.