Der known_hosts -Datei lässt den Client den Server authentifizieren, um zu überprüfen, ob er sich nicht mit einem Imitator verbindet. Die authorized_keys Datei lässt den Server den Benutzer authentifizieren.
Serverauthentifizierung
Eines der ersten Dinge, die beim Aufbau der SSH-Verbindung passieren, ist, dass der Server seinen öffentlichen Schlüssel an den Client sendet und dem Client (dank der Public-Key-Kryptografie) beweist, dass er den zugehörigen privaten Schlüssel kennt. Dies authentifiziert den Server:Wenn dieser Teil des Protokolls erfolgreich ist, weiß der Client, dass der Server derjenige ist, für den er sich ausgibt.
Der Client kann überprüfen, ob der Server ein bekannter ist und nicht irgendein bösartiger Server, der versucht, sich als der richtige auszugeben. SSH bietet nur einen einfachen Mechanismus, um die Legitimität des Servers zu überprüfen:Es merkt sich Server, mit denen Sie sich bereits verbunden haben, im ~/.ssh/known_hosts Datei auf dem Client-Rechner (es gibt auch eine systemweite Datei /etc/ssh/known_hosts ). Wenn Sie sich zum ersten Mal mit einem Server verbinden, müssen Sie auf andere Weise überprüfen, ob der vom Server präsentierte öffentliche Schlüssel wirklich der öffentliche Schlüssel des Servers ist, mit dem Sie sich verbinden wollten. Wenn Sie den öffentlichen Schlüssel des Servers haben, mit dem Sie sich verbinden möchten, können Sie ihn zu ~/.ssh/known_hosts hinzufügen auf dem Client manuell.
Übrigens known_hosts kann jede Art von öffentlichem Schlüssel enthalten, der von der SSH-Implementierung unterstützt wird, nicht nur DSA (auch RSA und ECDSA).
Der Server muss authentifiziert werden, bevor Sie vertrauliche Daten an ihn senden. Insbesondere wenn die Benutzerauthentifizierung ein Passwort beinhaltet, darf das Passwort nicht an einen nicht authentifizierten Server gesendet werden.
Benutzerauthentifizierung
Der Server lässt einen Remote-Benutzer sich nur anmelden, wenn dieser Benutzer nachweisen kann, dass er das Recht hat, 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 präsentieren (die Liste unten ist nicht vollständig).
- Der Benutzer kann das Passwort für das Konto angeben, in das er sich einzuloggen versucht; der Server überprüft dann, ob das Passwort 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 nachzuweisen, 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 Berechtigungsliste des Kontos steht (
~/.ssh/authorized_keysauf dem Server). - Eine andere Art von Methode besteht darin, einen Teil der Arbeit zur Authentifizierung des Benutzers an den Client-Rechner zu delegieren. Dies geschieht in kontrollierten Umgebungen wie Unternehmen, wenn viele Computer dieselben Konten verwenden. Der Server authentifiziert den Client-Rechner durch denselben Mechanismus, der umgekehrt verwendet wird, und verlässt sich dann darauf, dass der Client den Benutzer authentifiziert.
Diese beiden Dateien werden beide von SSH verwendet, aber für völlig unterschiedliche 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, eigentlich von PAM verwaltet, aber diese Unterscheidung ist hier wahrscheinlich nicht allzu nützlich.) Das bedeutet, dass, wenn Sie versuchen, sich mit dem Benutzernamen „bob“ und einem Passwort mit SSH zu verbinden, das SSH-Serverprogramm das Betriebssystem fragt:„I Ich habe diesen Typen namens ‚Bob‘, der mir sagt, sein Passwort sei ‚wonka‘. Kann ich ihn reinlassen?“ Wenn die Antwort ja ist, erlaubt SSH Ihnen, sich zu authentifizieren, und Sie können Ihrer fröhlichen Reise nachgehen.
Zusätzlich zu Passwörtern ermöglicht SSH Ihnen auch die sogenannte Public-Key-Kryptographie, um sich zu identifizieren. Der spezifische Verschlüsselungsalgorithmus kann variieren, ist aber normalerweise RSA oder DSA oder neuerdings ECDSA. In jedem Fall beim Einrichten Ihrer Schlüssel mit dem ssh-keygen Programm erstellen Sie zwei Dateien. Einer, der Ihr privater Schlüssel ist, und einer, der Ihr öffentlicher Schlüssel ist. Die Namen sind ziemlich selbsterklärend. Per Design kann der öffentliche Schlüssel wie Löwenzahnsamen im Wind verstreut werden, ohne Sie zu gefährden. Der private Schlüssel sollte immer streng vertraulich behandelt werden.
Was Sie also tun, ist Ihren öffentlichen Schlüssel in authorized_keys zu platzieren Datei. Wenn Sie dann versuchen, sich mit dem Benutzernamen „bob“ und Ihrem privaten Schlüssel mit SSH zu verbinden, wird das Betriebssystem gefragt:„Ich habe diesen Typen namens „bob“, kann er hier sein?“ Wenn die Antwort ja ist, überprüft SSH Ihren privaten Schlüssel und überprüft, ob der öffentliche Schlüssel in authorized_keys ist Datei ist ihr Paar. Wenn beide Antworten ja sind, dürfen Sie eintreten.
Bekannte Hosts
Ähnlich wie bei authorized_keys Datei wird verwendet, um Benutzer mit dem known_hosts zu authentifizieren Datei wird verwendet, um Server zu authentifizieren. Immer wenn SSH auf einem neuen Server konfiguriert wird, generiert es immer einen öffentlichen und einen privaten Schlüssel für den Server, genau wie Sie es für Ihren Benutzer getan haben. Jedes Mal, wenn Sie sich mit einem SSH-Server verbinden, zeigt er Ihnen seinen öffentlichen Schlüssel zusammen mit einem Nachweis, dass er den entsprechenden privaten Schlüssel besitzt. Wenn Sie seinen öffentlichen Schlüssel nicht haben, fragt Ihr Computer danach und fügt ihn dem known_hosts hinzu Datei. Wenn Sie den Schlüssel haben und er passt, dann verbinden Sie sich sofort. Wenn die Schlüssel nicht übereinstimmen, dann erhalten Sie eine große böse Warnung. Hier wird es interessant. Die 3 Situationen, in denen ein Schlüsselkonflikt normalerweise auftritt, sind:
- Der Schlüssel wurde auf dem Server geändert. Dies kann an der Neuinstallation des Betriebssystems liegen, oder bei einigen Betriebssystemen wird der Schlüssel beim Aktualisieren von SSH neu erstellt.
- Der Hostname oder die IP-Adresse, mit der Sie sich verbinden, gehörte früher zu einem anderen Server. Dies kann eine Adressneuzuweisung, DHCP oder ähnliches sein.
- Es findet ein böswilliger Man-in-the-Middle-Angriff statt. Das ist das Größte, wovor die Schlüsselüberprüfung Sie zu schützen versucht.
In beiden Fällen known_hosts und authorized_keys verwendet das SSH-Programm Public-Key-Kryptographie, um entweder den Client oder den Server zu identifizieren.
Über sichere Dateien mit öffentlichen Schlüsseln
Um Ihnen zu helfen zu verstehen, wie sich „known_hosts“ und „authorized_keys“ unterscheiden, finden Sie hier einen Kontext, der erklärt, wie diese Dateien in „ssh“ passen. Dies ist eine zu starke Vereinfachung; "ssh" hat viel mehr Fähigkeiten und Komplikationen als hier erwähnt.
Verknüpfungen befinden sich in vertrauenswürdigen Quellen
Während gesagt wurde, dass Public-Key-Werte „sicher wie Samen im Wind verstreut werden können“, denken Sie daran, dass es der Gärtner ist, nicht die Samenkapsel, die entscheidet, welche Samen im Garten wachsen. Obwohl ein öffentlicher Schlüssel nicht geheim ist, ist ein strenger Schutz erforderlich, um die vertrauenswürdige Zuordnung des Schlüssels zu dem Ding zu bewahren, das der Schlüssel authentifiziert. Zu den Stellen, denen diese Zuordnung anvertraut wurde, gehören „known_hosts“, „authorized_keys“ und „Certificate Authority“-Auflistungen.
Die von "ssh" verwendeten vertrauenswürdigen Quellen
Damit ein öffentlicher Schlüssel für „ssh“ relevant ist, muss der Schlüssel vorab registriert und in der entsprechenden sicheren Datei gespeichert werden. (Diese allgemeine Wahrheit hat eine wichtige Ausnahme, die später besprochen wird.) Der Server und der Client haben jeweils ihre eigene, sicher gespeicherte Liste öffentlicher Schlüssel; ein Login gelingt nur, wenn beide Seiten bei der anderen registriert sind.
- "known_hosts" befindet sich auf dem Client
- „authorized_keys“ befindet sich auf dem Server
Die sichere Datei des Clients heißt „known_hosts“, und die sichere Datei des Servers heißt „authorized_keys“. Diese Dateien sind sich darin ähnlich, dass jede Text mit einem öffentlichen Schlüssel pro Zeile enthält, aber sie haben geringfügige Unterschiede in Format und Verwendung.
Schlüsselpaare werden zur Authentifizierung verwendet
Ein öffentlich-privates Schlüsselpaar wird verwendet, um "asymmetrische Kryptografie" durchzuführen. Das „ssh“-Programm kann asymmetrische Kryptografie zur Authentifizierung verwenden, bei der eine Entität eine Herausforderung beantworten muss, um ihre Identität nachzuweisen. Die Herausforderung wird durch Codieren mit einem Schlüssel erstellt und durch Decodieren mit dem anderen Schlüssel beantwortet. (Beachten Sie, dass asymmetrische Kryptographie 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 den Server, ein anderes für den Client
Bei "ssh" sind beide Seiten (Client und Server) misstrauisch gegenüber dem anderen; dies ist eine Verbesserung gegenüber dem Vorgänger von „ssh“, der „telnet“ war. Bei „telnet“ musste der Client ein Passwort angeben, aber der Server wurde 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 preis, bis der Server zuerst auf eine Anfrage antwortet.
Die Schritte der "ssh"-Authentifizierung
Vor der Weitergabe von Anmeldeinformationen eliminiert der „ssh“-Client zunächst die Gelegenheit für einen Man-in-the-Middle-Angriff, indem er den Server herausfordert, zu beweisen:„Bist du wirklich der, für den ich dich halte?“ Um diese Abfrage durchzuführen, muss der Client den öffentlichen Schlüssel kennen, der dem Zielserver zugeordnet ist. Der Client muss den Namen des Servers in der Datei „known_hosts“ finden; der zugehörige öffentliche Schlüssel befindet sich in derselben Zeile nach dem Servernamen. Die Zuordnung zwischen Servername und öffentlichem Schlüssel muss unantastbar bleiben; daher müssen die Berechtigungen für die Datei „known_hosts“ 600 sein – niemand sonst kann schreiben (oder lesen).
Sobald sich der Server authentifiziert hat, erhält er die Möglichkeit, den Client herauszufordern. Die Authentifizierung beinhaltet einen der öffentlichen Schlüssel, die in den "authorized_keys" gefunden werden. (Wenn keiner dieser Schlüssel funktioniert, greift der „sshd“-Prozess auf die Authentifizierung im Passwortstil zurück.)
Die Dateiformate
Für „ssh“ gibt es also wie bei jedem Anmeldeprozess Listen mit „Freunden“, und nur diejenigen auf der Liste dürfen versuchen, eine Herausforderung zu bestehen. Für den Client ist die Datei „known_hosts“ eine Liste von Freunden, die als Server (Hosts) fungieren können; diese sind namentlich aufgeführt. Für den Server ist die entsprechende Freundesliste die Datei „authorized_keys“; aber es gibt keine Namen in dieser Datei, da die öffentlichen Schlüssel selbst wie Identifikatoren fungieren. (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. Denken Sie daran, dass die Datei „authorized_keys " Datei ist spezifisch für dieses Konto, da sich die Datei im Home-Verzeichnis dieses Kontos befindet.)
Obwohl es viele Fähigkeiten gibt, die in einem Konfigurationseintrag ausgedrückt werden können, hat die grundlegende, häufigste Verwendung die folgenden Parameter. Beachten Sie, dass Parameter durch Leerzeichen getrennt werden.
Für "bekannte_Hosts":
{server-id} ssh-rsa {public-key-string} {comment}
Für "autorisierte_Schlüssel":
ssh-rsa {public-key-string} {comment}
Beachten Sie, dass das Token ssh-rsa gibt an, dass der für die Codierung verwendete Algorithmus "rsa" ist. Andere gültige Algorithmen sind "dsa" und "ecdsa". Daher kann ein anderes Token den Platz von ssh-rsa einnehmen hier gezeigt.
Lassen Sie "ssh" den Eintrag "known_hosts" automatisch konfigurieren
Wenn der öffentliche Schlüssel nicht in einer sicheren Datei gefunden wird, findet in beiden Fällen keine asymmetrische Verschlüsselung statt. Wie bereits erwähnt, gibt es eine Ausnahme von dieser Regel. Ein Benutzer darf sich bewusst 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 „known_hosts“-Datei des Benutzers aufgeführt ist. Das „ssh“-Programm warnt den Benutzer, aber wenn der Benutzer fortfahren möchte, lässt der „ssh“-Client dies „nur dieses eine Mal“ zu. Um sicherzustellen, dass dies nur einmal passiert, konfiguriert der „ssh“-Prozess automatisch die Datei „known_hosts“ mit den erforderlichen Informationen, indem er den Server nach dem öffentlichen Schlüssel fragt und diesen dann in die Datei „known_hosts“ schreibt. Diese Ausnahme untergräbt die Sicherheit vollständig, indem sie es dem Angreifer ermöglicht, die Zuordnung eines Servernamens zu einem öffentlichen Schlüssel bereitzustellen. Dieses Sicherheitsrisiko ist erlaubt, weil es für so viele Menschen so viel einfacher macht. Natürlich wäre es die richtige und sichere Methode gewesen, wenn der Benutzer manuell eine Zeile mit dem Servernamen und dem öffentlichen Schlüssel in die Datei „known_hosts“ eingefügt hätte, bevor er jemals versucht hätte, sich beim Server anzumelden. (Aber in Situationen mit geringem Risiko kann die zusätzliche Arbeit sinnlos sein.)
Die 1:n-Beziehungen
Ein Eintrag in der "known_hosts"-Datei des Clients hat den Namen eines Servers und einen öffentlichen Schlüssel, der auf die Servermaschine anwendbar ist. Der Server hat einen einzigen privaten Schlüssel, der verwendet wird, um alle Abfragen zu beantworten, und der „known_hosts“-Eintrag des Clients muss den passenden öffentlichen Schlüssel haben. Daher haben alle Clients, die jemals auf einen bestimmten Server zugreifen, den identischen Public-Key-Eintrag in ihrer "known_hosts"-Datei. Die 1:N-Beziehung besteht darin, dass der öffentliche Schlüssel eines Servers in den "known_hosts"-Dateien vieler Clients erscheinen kann.
Ein Eintrag in der Datei „authorized_keys“ gibt an, dass ein freundlicher Client auf das Konto zugreifen darf. Der Freund verwendet möglicherweise dasselbe öffentlich-private Schlüsselpaar, um auf mehrere verschiedene Server zuzugreifen. Dadurch kann sich ein einzelnes Schlüsselpaar bei allen jemals kontaktierten Servern authentifizieren. Jedes der Zielserverkonten hätte den identischen Eintrag des öffentlichen Schlüssels in seinen „authorized_keys“-Dateien. Die 1:N-Beziehung besteht darin, dass der öffentliche Schlüssel eines Clients in den "authorized_keys"-Dateien für mehrere Konten auf mehreren Servern erscheinen kann.
Manchmal replizieren Benutzer, die von mehreren Client-Rechnern aus arbeiten, dasselbe Schlüsselpaar; typischerweise geschieht dies, wenn ein Benutzer an einem Desktop und einem Laptop arbeitet. Da sich die Client-Maschinen mit identischen Schlüsseln authentifizieren, stimmen sie mit demselben Eintrag in den „authorized_keys“ des Servers überein.
Speicherort privater Schlüssel
Auf der Serverseite verarbeitet ein Systemprozess oder Daemon alle eingehenden "ssh"-Anmeldeanforderungen. 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 ab , aber nach der Installation Ihrer eigenen Version von OpenSSL lautet der Speicherort /opt/local/etc/openssl .
Auf der Client-Seite rufen Sie "ssh" (oder "scp") auf, wenn Sie es brauchen. Ihre Befehlszeile enthält verschiedene Parameter, von denen einer optional angeben kann, welcher private Schlüssel verwendet werden soll. Standardmäßig werden die clientseitigen Schlüsselpaare oft als $HOME/.ssh/id_rsa bezeichnet und $HOME/.ssh/id_rsa.pub .
Zusammenfassung
Fazit ist, dass sowohl "known_hosts" als auch "authorized_keys" öffentliche Schlüssel enthalten, aber ...
- known_hosts – der Client prüft, ob der Host echt ist
- authorized_keys – der Host prüft, ob die Client-Anmeldung erlaubt ist