Mit der Datei known_hosts kann der Client den Server authentifizieren, um zu überprüfen, ob keine Verbindung zu einem Imitator hergestellt wird. Mit der Datei authorized_keys kann Der Server authentifiziert den Benutzer.

Serverauthentifizierung

Eines der ersten Dinge, die beim Herstellen der SSH-Verbindung passieren, ist, dass der Server seinen öffentlichen Schlüssel an den Client sendet und dies beweist (Dank Kryptografie mit öffentlichem Schlüssel ) an den Client, dass er den zugehörigen privaten Schlüssel kennt. Dies authentifiziert den Server: Wenn dieser Teil des Protokolls erfolgreich ist, wird der Der Client weiß, dass der Server der ist, für den er sich ausgibt.

Der Client überprüft möglicherweise, ob es sich bei dem Server um einen bekannten Server handelt und nicht um einen nicht autorisierten Server versuchen, als der richtige auszugeben. SSH bietet nur einen einfachen Mechanismus zum Überprüfen der Legitimität des Servers: Es speichert Server, mit denen Sie bereits verbunden sind, in der Datei ~/.ssh/known_hosts auf dem Clientcomputer (es gibt auch ein System) -weite Datei /etc/ssh/known_hosts). Wenn Sie zum ersten Mal eine Verbindung zu einem Server herstellen, müssen Sie auf andere Weise überprüfen, ob der vom Server präsentierte öffentliche Schlüssel tatsächlich der öffentliche Schlüssel des Servers ist Sie wollten eine Verbindung herstellen. Wenn Sie den öffentlichen Schlüssel des Servers haben, zu dem Sie eine Verbindung herstellen möchten, können Sie ihn manuell zu ~/.ssh/known_hosts auf dem Client hinzufügen.

Übrigens kann known_hosts jede Art von öffentlichem Schlüssel enthalten, der von der SSH-Implementierung unterstützt wird, nicht nur DSA (auch RSA und ECDSA).

Authentifizierung des Der Server muss ausgeführt werden, bevor Sie vertrauliche Daten an ihn senden. Insbesondere wenn die Benutzerauthentifizierung ein Kennwort umfasst, darf das Kennwort nicht an einen nicht authentifizierten Server gesendet werden.

Benutzerauthentifizierung

Der Server lässt einen Remotebenutzer nur dann anmelden, wenn dieser Benutzer angemeldet ist kann nachweisen, dass sie das Recht haben, auf dieses Konto zuzugreifen. Abhängig von der Konfiguration des Servers und der Wahl des Benutzers kann der Benutzer eine von mehreren Arten von Anmeldeinformationen vorlegen (die folgende Liste ist nicht vollständig).

• Der Benutzer kann das Kennwort für angeben das Konto, in das er sich einloggen möchte; Der Server überprüft dann, ob das Kennwort korrekt ist.
• Der Benutzer kann einen öffentlichen Schlüssel vorlegen und nachweisen, dass er den mit diesem öffentlichen Schlüssel verknüpften privaten Schlüssel besitzt. Dies ist genau die gleiche Methode, die zur Authentifizierung des Servers verwendet wird, aber jetzt versucht der Benutzer, seine Identität zu beweisen, und der Server überprüft sie. Der Anmeldeversuch wird akzeptiert, wenn der Benutzer nachweist, dass er den privaten Schlüssel kennt und der öffentliche Schlüssel in der Autorisierungsliste des Kontos enthalten ist (~/.ssh/authorized_keys auf dem Server).

ine andere Art von Methode besteht darin, einen Teil der Authentifizierungsarbeit des Benutzers an den Clientcomputer zu delegieren. Dies geschieht in kontrollierten Umgebungen wie Unternehmen, in denen viele Computer dieselben Konten verwenden. Der Server authentifiziert den Clientcomputer nach demselben Mechanismus Wird umgekehrt verwendet und verlässt sich dann auf den Client, um den Benutzer zu authentifizieren.

Kommentare

• Vielen Dank, dies ist sehr hilfreich Es ist richtig zu sagen, dass die Datei „unknown_hosts“ auf dem Client verwaltet wird, während die Datei „authored_key“ auf dem Server verwaltet wird.
• @Ankit Ja, das ist der Fall.
• Ich habe beide Dateien auf dem Server und ssh dazu, um es zu testen. Aber die 2 Dateien haben unterschiedliche Inhalte. Also sind die Schlüssel in diesen Dateien unterschiedlich?
• @Timo Die Schlüssel sind völlig unr begeistert. Einer ist der Schlüssel eines Computers, der andere ist der Schlüssel eines Benutzers.
• @Gilles Sobald also der Eintrag für den öffentlichen Schlüssel eines Servers ‚ hinzugefügt wurde In der bekannten_Hosts -Datei auf dem Client ‚ wird jede nachfolgende ssh-Sitzung zwischen den beiden nicht ‚ t Der Server muss nachweisen, dass er über den richtigen privaten Schlüssel verfügt.

Diese beiden Dateien werden beide von verwendet SSH aber für ganz andere Zwecke, was Ihre Verwirrung leicht erklären könnte.

Autorisierte Schlüssel

Standardmäßig verwendet SSH Benutzerkonten und Kennwörter, die vom Host-Betriebssystem verwaltet werden. (Nun, tatsächlich verwaltet von PAM , aber diese Unterscheidung ist hier wahrscheinlich nicht allzu nützlich.) Dies bedeutet, dass Sie versuchen, mit dem Benutzernamen eine Verbindung zu SSH herzustellen „bob“ und ein Passwort Das SSH-Serverprogramm fragt das Betriebssystem “ Ich habe diesen Typen namens „bob“, der mir sagt, sein Passwort sei „wonka“. Kann ich ihn hereinlassen? “ Wenn die Antwort Ja lautet, können Sie sich mit SSH authentifizieren und Ihren lustigen Weg gehen.

Zusätzlich zu den Passwörtern SSH Sie können auch die so genannte Kryptographie mit öffentlichem Schlüssel verwenden, um Sie zu identifizieren. Der spezifische Verschlüsselungsalgorithmus kann variieren, ist jedoch normalerweise RSA oder DSA oder in jüngerer Zeit ECDSA . In jedem Fall, wenn Sie Ihre Schlüssel einrichten, verwenden Sie die ssh-keygen erstellen Sie zwei Dateien. Eine ist Ihr privater Schlüssel und eine Ihr öffentlicher Schlüssel. Die Namen sind ziemlich selbst -erklärend. Der öffentliche Schlüssel kann wie Löwenzahnsamen im Wind verteilt werden, ohne Sie zu gefährden. Der private Schlüssel sollte immer streng vertraulich behandelt werden.

Sie platzieren also Ihren öffentlichen Schlüssel Geben Sie die Datei authorized_keys ein. Wenn Sie dann versuchen, eine Verbindung zu SSH mit dem Benutzernamen „bob“ und herzustellen Ihr privater Schlüssel fragt das Betriebssystem “ Ich habe diesen Typennamen „bob“, kann er hier sein? “ Wenn die Antwort lautet Ja, dann überprüft SSH Ihren privaten Schlüssel und überprüft, ob der öffentliche Schlüssel in der Datei authorized_keys sein Paar ist. Wenn beide Antworten Ja lauten, dürfen Sie sich anmelden.

Bekannte Hosts

Ähnlich wie die Datei authorized_keys zur Authentifizierung von Benutzern verwendet wird Die Datei known_hosts wird zur Authentifizierung von Servern verwendet. Wenn SSH auf einem neuen Server konfiguriert wird, wird immer ein öffentlicher und ein privater Schlüssel für den Server generiert, genau wie Sie es für Ihren Benutzer getan haben. Jedes Mal, wenn Sie eine Verbindung zu einem SSH-Server herstellen, wird Ihnen dessen öffentlicher Schlüssel zusammen mit dem Nachweis angezeigt, dass er den entsprechenden privaten Schlüssel besitzt. Wenn Sie keinen öffentlichen Schlüssel haben, fragt Ihr Computer danach und fügt ihn der Datei known_hosts hinzu. Wenn Sie den Schlüssel haben und dieser übereinstimmt, stellen Sie sofort eine Verbindung her. Wenn die Schlüssel nicht übereinstimmen, erhalten Sie eine große böse Warnung. Hier wird es interessant. Die drei Situationen, in denen eine Schlüsselinkongruenz normalerweise auftritt, sind:

1. Der Schlüssel wurde auf dem Server geändert. Dies kann durch eine Neuinstallation des Betriebssystems oder unter einigen Betriebssystemen geschehen, bei denen der Schlüssel beim Aktualisieren von SSH neu erstellt wird.
2. Der Hostname oder die IP-Adresse, die Sie verbinden zu einem anderen Server gehören. Dies kann eine Neuzuweisung von Adressen sein, DHCP oder ähnliches.
3. Bösartiges man- In-the-Middle-Angriff findet statt. Dies ist die größte Sache, vor der die Schlüsselprüfung Sie schützen möchte.

In beiden Fällen known_hosts und authorized_keys verwendet das SSH-Programm die Kryptografie mit öffentlichem Schlüssel, um entweder den Client oder den Server zu identifizieren.

Kommentare

• “ Jedes Mal, wenn Sie eine Verbindung zu einem SSH-Server herstellen, wird dessen privater Schlüssel angezeigt, um seine Identität zu beweisen. “ Ich hoffe es nicht! Ich nehme an, Sie meinten seinen öffentlichen Schlüssel . Wenn mir ein Server den Client mit seinem privaten Schlüssel präsentieren würde, würde es (A) ‚ für mich nicht funktionieren, um ihn zu authentifizieren, und (B) ist ein Hinweis darauf, dass der Server dies ist schlecht konfiguriert, dass ich sofort aufhören sollte, damit Geschäfte zu machen. Private Schlüssel sollten nur für bestimmte Benutzer auf dem Ursprungscomputer zugänglich sein. Das ‚ ist irgendwie der Punkt. 😉
• Diese Antwort hat mir mehr geholfen als die akzeptierte (:
• Wenn ich auf einen lokalen Server (lokale IP) ssh und später vom selben Computer, aber jetzt remote Wenn Sie eine Verbindung zum selben Server (öffentliche IP) herstellen, werden nicht übereinstimmende Schlüssel ausgelöst. Wie können Sie dies verringern?

Informationen zu sicheren Dateien mit öffentlichen Schlüsseln

Um zu verstehen, wie sich „bekannte_Hosts“ und „autorisierte_Tasten“ unterscheiden, finden Sie hier einen Kontext, in dem erläutert wird, wie diese Dateien in „ssh“ passen. Dies ist eine übermäßige Vereinfachung ; ssh bietet viel mehr Möglichkeiten und Komplikationen als hier erwähnt.

Assoziationen befinden sich in vertrauenswürdigen Quellen

Obwohl gesagt wurde, dass Public-Key-Werte „sicher wie Samen im Wind verstreut werden können“, denken Sie daran, dass dies der Fall ist Gärtner, nicht die Samenschale, die entscheidet, welche Samen im Garten etabliert werden. Obwohl ein öffentlicher Schlüssel nicht geheim ist, ist ein strenger Schutz erforderlich, um die vertrauenswürdige Zuordnung des Schlüssels zu dem zu bewahren, was der Schlüssel authentifiziert. Die Orte Mit der Zuordnung dieser Zuordnung sind die Listen „Bekannte_Hosts“, „Autorisierte_Schlüssel“ und „Zertifizierungsstelle“ beauftragt.

Die von „ssh“

verwendeten vertrauenswürdigen Quellen Für einen öffentlichen Schlüssel Für „ssh“ relevant, muss der Schlüssel im Voraus registriert und in der entsprechenden sicheren Datei gespeichert werden. (Diese allgemeine Wahrheit hat eine wichtige Ausnahme, die später erläutert wird.) Der Server und der Client haben jeweils ihre eigenen, sicher gespeicherten Dateien Liste der öffentlichen Schlüssel; eine Anmeldung ist nur dann erfolgreich, wenn jede Seite bei der anderen registriert ist.

• „unknown_hosts“ befindet sich auf dem Clie nt
• „autorisierte_Tasten“ befinden sich auf dem Server

Die sichere Datei des Clients heißt „bekannte_Hosts“, und die sichere Datei des Servers heißt „autorisierte_Tasten“. . Diese Dateien sind insofern ähnlich, als jede Datei Text mit einem öffentlichen Schlüssel pro Zeile enthält, sie weisen jedoch geringfügige Unterschiede in Format und Verwendung auf.

Schlüsselpaare werden zur Authentifizierung verwendet

Eine öffentliche Person -private Schlüsselpaare werden verwendet, um „asymmetrische Kryptographie“ durchzuführen. Das „ssh“ -Programm kann zur Authentifizierung asymmetrische Kryptografie verwenden, bei der eine Entität eine Herausforderung beantworten muss, um ihre Identität zu beweisen. Die Herausforderung wird durch Codieren mit einem Schlüssel erstellt und durch Decodieren mit dem anderen Schlüssel beantwortet. (Beachten Sie, dass asymmetrische Kryptogrophie nur während der Anmeldephase verwendet wird. Dann wechselt „ssh“ (TSL / SSL) zu einer anderen Form der Verschlüsselung, um den Datenstrom zu verarbeiten.)

Ein Schlüsselpaar für Server, ein anderes für Client

In „ssh“ sind beide Seiten (Client und Server) dem anderen gegenüber misstrauisch; Dies ist eine Verbesserung gegenüber dem Vorgänger von „ssh“, der „telnet“ war. Bei „Telnet“ musste der Client ein Kennwort angeben, der Server wurde jedoch nicht überprüft. Das Fehlen einer Überprüfung ermöglichte „Man-in-the-Middle“ -Angriffe mit katastrophalen Folgen für die Sicherheit. Im Gegensatz dazu gibt der Client beim „ssh“ -Prozess keine Informationen ab, bis der Server zum ersten Mal eine Herausforderung beantwortet.

Die Schritte zur „ssh“ -Authentifizierung

Bevor Sie Anmeldeinformationen freigeben, Der „ssh“ -Client eliminiert zunächst die Möglichkeit eines Man-in-the-Middle-Angriffs, indem er den Server auffordert, zu beweisen, dass Sie wirklich der sind, für den ich Sie halte. Um diese Herausforderung zu bewältigen, muss der Client den öffentlichen Schlüssel kennen, der dem Zielserver zugeordnet ist. Der Client muss den Namen des Servers in der Datei „unknown_hosts“ finden. Der zugehörige öffentliche Schlüssel befindet sich nach dem Servernamen in derselben Zeile. Die Zuordnung zwischen Servername und öffentlichem Schlüssel muss unberührt bleiben. Daher sind die Berechtigungen aktiviert Die Datei „unknown_hosts“ muss 600 sein – niemand kann schreiben (oder lesen).

Sobald sich der Server authentifiziert hat, kann er den Client herausfordern. An der Authentifizierung wird einer der öffentlichen Benutzer beteiligt. Schlüssel in den „autorisierten Schlüsseln“. (Wenn keiner dieser Schlüssel funktioniert, greift der „sshd“ -Prozess auf die Authentifizierung im Kennwortstil zurück.)

Die Dateiformate

Also für “ ssh „, wie bei jedem Anmeldevorgang, gibt es Listen mit“ Freunden „, und nur diejenigen auf der Liste dürfen versuchen, eine Herausforderung zu bestehen. Für den Client ist die Datei“ unknown_hosts „eine Liste von Freunden, die als fungieren können Server (Hosts), diese werden nach Namen aufgelistet. Für den Server ist die entsprechende Liste von Freunden die Datei „autorisierte_Tasten“, aber diese Datei enthält keine Namen, da die Veröffentlichung c-Tasten selbst wirken wie Bezeichner. (Dem Server ist es egal, woher die Anmeldung kommt, sondern nur, wohin sie geht. Der Client versucht, auf ein bestimmtes Konto zuzugreifen. Der Kontoname wurde als Parameter angegeben, als „ssh“ aufgerufen wurde Die Datei „authorized_keys“ ist spezifisch für dieses Konto, da sich die Datei im Ausgangsverzeichnis dieses Kontos befindet.)

Obwohl es viele Funktionen gibt, die in einem Konfigurationseintrag ausgedrückt werden können, ist dies die grundlegende, häufigste Verwendung hat die folgenden Parameter. Beachten Sie, dass die Parameter durch Leerzeichen getrennt sind.

Für „bekannte_Hosts“:

{server-id} ssh-rsa {public-key-string} {comment} 

Für „autorisierte_Tasten“:

ssh-rsa {public-key-string} {comment} 

Beachten Sie, dass das Token ssh-rsa angibt, dass der für die Codierung verwendete Algorithmus „rsa“ ist. Andere gültige Algorithmen Fügen Sie „dsa“ und „ecdsa“ hinzu. Daher kann ein anderes Token den hier gezeigten ssh-rsa ersetzen.

Lassen Sie „ssh“ das automatisch konfigurieren Eintrag „unknown_hosts“

In beiden Fällen, wenn th Wenn der öffentliche Schlüssel nicht in einer sicheren Datei gefunden wird, findet keine assymetrische Verschlüsselung statt. Wie bereits erwähnt, gibt es eine Ausnahme von dieser Regel.Ein Benutzer kann sich wissentlich dafür entscheiden, die Möglichkeit eines Man-in-the-Middle-Angriffs zu riskieren, indem er sich bei einem Server anmeldet, der nicht in der Datei „unknown_hosts“ des Benutzers aufgeführt ist. Das Programm „ssh“ warnt den Benutzer jedoch Wenn der Benutzer vorwärts gehen möchte, lässt der „ssh“ -Client dies „nur einmal“ zu. Um sicherzustellen, dass dies nur einmal geschieht, konfiguriert der „ssh“ -Prozess die Datei „unknown_hosts“ automatisch mit den erforderlichen Informationen, indem er den Server nach dem fragt public-key und dann das Schreiben in die Datei „unknown_hosts“. Diese Ausnahme untergräbt die Sicherheit vollständig, indem der Gegner die Zuordnung eines Servernamens zu einem öffentlichen Schlüssel zulässt. Dieses Sicherheitsrisiko ist zulässig, weil es die Dinge so stark macht Für so viele Menschen einfacher. Natürlich wäre die richtige und sichere Methode für den Benutzer gewesen, manuell eine Zeile mit Servername und öffentlichem Schlüssel in die Datei „unknown_hosts“ einzufügen, bevor er jemals versucht, sich beim Server anzumelden In Situationen mit geringem Risiko ist die zusätzliche Arbeit möglicherweise sinnlos.)

Die Eins-zu-Viele-Beziehungen

Ein Eintrag in der Datei „Bekannte_Hosts“ des Clients enthält den Namen eines Servers und einen öffentlichen Schlüssel, der auf den Servercomputer anwendbar ist. Der Server verfügt über einen einzelnen privaten Schlüssel, mit dem alle Herausforderungen beantwortet werden, und der Eintrag „Bekannte_Hosts“ des Clients muss über den entsprechenden öffentlichen Schlüssel verfügen. Daher verfügen alle Clients, die jemals auf einen bestimmten Server zugreifen, über den gleichen öffentlichen Schlüssel Eintrag in ihrer „Bekannten_Hosts“ -Datei. Die 1: N-Beziehung besteht darin, dass der öffentliche Schlüssel eines Servers in den „Bekannten_Hosts“ -Dateien vieler Clients angezeigt werden kann.

Ein Eintrag in der „Authorized_keys“ -Datei identifiziert dass ein freundlicher Client auf das Konto zugreifen darf. Der Freund verwendet möglicherweise dasselbe öffentlich-private Schlüsselpaar, um auf mehrere unterschiedliche Server zuzugreifen. Dadurch kann sich ein einzelnes Schlüsselpaar bei allen Servern authentifizieren, die jemals kontaktiert wurden. Jedes der Zielserverkonten Die identische 1: N-Beziehung besteht darin, dass der öffentliche Schlüssel eines Clients in den „autorisierten Schlüssel“ -Dateien für mehrere Konten auf mehreren Servern angezeigt werden kann.

Manchmal replizieren Benutzer, die von mehreren Clientcomputern aus arbeiten, dasselbe Schlüsselpaar. Dies geschieht normalerweise, wenn ein Benutzer an einem Desktop und einem Laptop arbeitet. Da sich die Clientcomputer mit identischen Schlüsseln authentifizieren, stimmen sie mit demselben Eintrag in den „autorisierten Schlüsseln“ des Servers überein.

Speicherort der privaten Schlüssel

Für die Serverseite ein Systemprozess Der Daemon heißt „sshd“. Der Speicherort des privaten Schlüssels hängt von der SSL-Installation ab. Apple legt ihn beispielsweise unter /System/Library/OpenSSL, aber nach der Installation Ihrer eigenen Version von OpenSSL lautet der Speicherort /opt/local/etc/openssl.

Auf der Clientseite rufen Sie „ssh“ (oder „scp“) auf. ) Wenn Sie es benötigen. Ihre Befehlszeile enthält verschiedene Parameter, von denen einer optional angeben kann, welcher private Schlüssel verwendet werden soll. Standardmäßig wird das clientseitige Schlüsselpaar häufig als $HOME/.ssh/id_rsa bezeichnet und $HOME/.ssh/id_rsa.pub.

Zusammenfassung

Fazit ist, dass sowohl „bekannte_Hosts“ als auch „autorisierte_Tasten“ öffentliche Schlüssel enthalten, aber …

• bekannte_Hosts – Der Client prüft, ob der Host echt ist
• autorisierte_Tasten – Der Host prüft, ob die Clientanmeldung zulässig ist.

Kommentare

• SSH-Clients verwenden normalerweise nicht ‚ haben keine Schlüssel. Die öffentlichen Schlüssel, die in authorized_keys aufgeführt sind, identifizieren Benutzer, keine Maschinen.
• Vielen Dank. Dies ist eine sehr klare und leicht verständliche Erklärung der Beziehungen zwischen den Dateien und den Schlüsseln.

Überhaupt nicht wahr.

Die Datei unknown_hosts enthält den Fingerabdruck des Hosts. Es ist nicht der öffentliche oder private Schlüssel des Remote-Hosts.

Es wird aus dessen Schlüssel generiert – aber es ist ausdrücklich NICHT der Schlüssel selbst.

Wenn Sie eine SFTP an eine Adresse senden, die Möglicherweise werden mehrere (unterschiedliche) Hosts (Lastausgleich usw.) aufgelöst. Sie müssen die Fingerabdrücke von allen möglichen Endpunkten hinzufügen. Andernfalls funktioniert dies zunächst und schlägt dann fehl, wenn es an den zweiten (oder nachfolgenden) Host weitergeleitet wird.

Kommentare

• ähm, sehen Sie sich Ihre Datei „unknown_hosts“ an und vergleichen Sie sie mit einem Host-Fingerabdruck, wenn Sie eine Verbindung herstellen. Das sollte es ein wenig klären. Darüber hinaus wäre Ihr Beispiel genau das gleiche, unabhängig davon, ob es sich um Fingerabdrücke oder öffentliche Schlüssel in der Datei unknown_hosts handelt.