SSH-Schlüssel-basierte Authentifizierung: Bekannte_Hosts vs. Autorisierte_Schlüssel


21

Ich habe etwas über das Einrichten von ssh-Schlüsseln unter Linux gelesen und habe einige Fragen. Korrigiere mich, wenn ich falsch liege ...

Nehmen wir an, Host tr-lgto möchte mit ssh eine Verbindung zu Host tr-mdm herstellen. Wenn wir sicher sein wollen, dass es sich um das echte tr-mdm handelt, generieren wir ein Schlüsselpaar auf tr-mdm und fügen den öffentlichen Schlüssel known_hostsauf tr-lgto hinzu. Wenn tr-mdm überprüfen möchte, ob es sich um das echte tr-lgto handelt, muss tr-lgto ein Schlüsselpaar generieren und den öffentlichen Schlüssel zu authorized_keystr-mdm hinzufügen.

Frage 1 : In der Datei known_hosts gibt es kein Benutzerfeld , nur IP-Adressen und Hostnamen. tr-mdm hat möglicherweise viele Benutzer, die jeweils einen eigenen .sshOrdner haben. Sollten wir den öffentlichen Schlüssel zu jeder der known_hostsDateien hinzufügen ?

Frage 2 : Ich habe festgestellt, dass ssh-keyscan -t rsa tr-mdmder öffentliche Schlüssel von tr-mdm zurückgegeben wird. Woher weiß ich, welchem ​​Benutzer dieser Schlüssel gehört? Darüber hinaus unterscheidet sich der öffentliche Schlüssel /root/.ssh/von dem, was dieser Befehl zurückgibt. Wie kann das sein?



Ich habe einen Hintergrundkontext für 'ssh' in einer Antwort "Über sichere Dateien mit öffentlichen Schlüsseln" auf die von @Gilles erwähnte Frage hinzugefügt: < security.stackexchange.com/questions/20706/… >
IAM_AL_X

Antworten:


33

Sie verwechseln die Authentifizierung des Servercomputers mit dem Clientcomputer und die Authentifizierung des Benutzers mit dem Servercomputer.

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 Public-Key-Kryptografie ) nachweist, 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 so ist, wie er es vorgibt.

Der Client überprüft möglicherweise, ob es sich um einen bekannten Server handelt, und nicht um einen Schurken-Server, der versucht, sich als der richtige auszugeben. SSH bietet nur einen einfachen Mechanismus zur Überprüfung der Legitimität des Servers: Es merkt sich die Server, mit denen Sie bereits verbunden sind, in der ~/.ssh/known_hostsDatei auf dem Client-Computer (es gibt auch eine systemweite 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 angegebene öffentliche Schlüssel wirklich der öffentliche Schlüssel des Servers ist, zu dem Sie eine Verbindung herstellen möchten. Wenn Sie den öffentlichen Schlüssel des Servers haben, zu dem Sie eine Verbindung herstellen möchten, können Sie ihn ~/.ssh/known_hostsmanuell auf dem Client hinzufügen .

Die Authentifizierung des Servers muss erfolgen, bevor Sie vertrauliche Daten an den Server senden. Insbesondere wenn die Benutzerauthentifizierung ein Kennwort enthält, darf das Kennwort nicht an einen nicht authentifizierten Server gesendet werden.

Benutzerauthentifizierung

Der Server lässt einen Remote-Benutzer nur dann anmelden, wenn dieser Benutzer nachweisen kann, dass er das Recht hat, auf dieses Konto zuzugreifen. Abhängig von der Serverkonfiguration und der Auswahl des Benutzers kann der Benutzer eine von mehreren Arten von Anmeldeinformationen vorlegen (die folgende Liste erhebt keinen Anspruch auf Vollständigkeit).

  • Der Benutzer kann das Kennwort für das Konto angeben, bei dem er sich anmelden 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 verbundenen privaten Schlüssel besitzt. Dies ist genau die gleiche Methode, die zur Authentifizierung des Servers verwendet wird. Jetzt versucht der Benutzer, seine Identität zu bestätigen, 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 ( ~/.ssh/authorized_keysauf dem Server) enthalten ist.
  • Eine andere Art von Verfahren umfasst das Delegieren eines Teils der Arbeit zum Authentifizieren des Benutzers an den Client-Computer. Dies geschieht in kontrollierten Umgebungen wie Unternehmen, in denen sich viele Computer dieselben Konten teilen. Der Server authentifiziert den Client-Computer mit dem gleichen Mechanismus, der umgekehrt verwendet wird, und verlässt sich dann auf den Client, um den Benutzer zu authentifizieren.

1
Gute Antwort Gilles, aber meine Frage ist, dass jeder Server einen zufälligen öffentlichen Schlüssel senden und nachweisen kann, dass er über den zugehörigen öffentlichen Schlüssel verfügt. Wie beweist das, dass der Server authentisch ist?
Alex

@spartacus Ich denke, Sie meinten "und beweisen, dass es den zugehörigen privaten Schlüssel hat", oder? Die Idee ist, dass der Client einen zufällig generierten Wert (eine Herausforderung ) an den Server sendet und der Server eine Berechnung basierend auf dem privaten Schlüssel durchführt, der von der Herausforderung abhängt (der Server kann die Berechnung also erst durchführen, wenn er diesen erhält Herausforderung) und das kann nur mit der Kenntnis des privaten Schlüssels erfolgen.
Gilles 'SO - hör auf böse zu sein'

Ich denke, Alex bezieht sich auf das erste Mal, wenn der Client eine Verbindung zum Server herstellt. Ich denke, der Client wird dem Server das erste Mal vertrauen. Anschließend sendet der Server seinen öffentlichen Schlüssel und der Client kann den Server für die folgenden Verbindungen authentifizieren.
Synack

@synack Ah, das erste mal? Vielmehr trifft der Client die Entscheidung des Benutzers („Möchten Sie die Verbindung wirklich fortsetzen (Ja / Nein)?“). Der Server beweist zu diesem Zeitpunkt nichts.
Gilles 'SO- hör auf böse zu sein'

Sie haben recht, es ist der Benutzer, der die Entscheidung trifft.
Synack

2

Meine Freunde gaben mir die Antwort. Standardmäßig identifiziert der Schlüssel einen Computer und keinen Benutzer. Die Schlüssel werden also in / etc / ssh / gespeichert. Aus diesem Grund habe ich einen anderen Schlüssel als den in /root/.ssh gespeicherten erhalten

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.