it-swarm.com.de

Mein Freund enthüllte sowohl private als auch öffentliche Schlüssel für seinen Server. Wie ernst ist das?

Einem Freund von mir ist es gelungen, sowohl die Datei id_rsa als auch die Datei id_rsa.pub über Apache von seinem Server verfügbar zu machen. Ich erwähnte ihm gegenüber, dass dies ein ernstes Sicherheitsproblem ist, aber er wischte dies ab, als wäre es keine große Sache. Kann mir hier jemand helfen, da ich nicht genug Sicherheitswissen besitze, um ihm zu erklären, warum dies schlecht ist? Oder vielleicht hat mein Freund recht und es ist nicht so schlimm, wie ich es mir vorstelle?

43
dkns

Ich nehme an, dass diese Dateien für "seinen SSH-Schlüssel" als Client sind.

Offenlegung des öffentlichen Schlüssels (id_rsa.pub) hat keine Konsequenz: Wenn wir es einen öffentlichen Schlüssel nennen, meinen wir es. Der private Schlüssel (id_rsa) ist natürlich das Problem.

Die Art und Weise, wie Sie als Client Ihren privaten Schlüssel verwenden, besteht darin, den entsprechenden öffentlichen Schlüssel im .ssh/authorized_keys des Zielkontos. Wenn sich der öffentliche Schlüssel in dieser Datei befindet, kann sich jeder, der den privaten Schlüssel kennt, unter diesem Namen beim Server anmelden. So funktionieren die öffentlichen/privaten Schlüssel auf der Clientseite in SSH.

Es gibt also grundsätzlich drei mögliche, rationale Gründe, die es Ihrem Freund ermöglichen würden, die Offenlegung seines id_rsa Datei:

  1. Vielleicht hat er den öffentlichen Schlüssel nie irgendwo gedrückt. Wenn er sich bei einem Server anmeldet, gibt er dazu immer sein Kontokennwort für diesen Server ein. Wenn sein Schlüsselpaar niemals verwendet wird , ist das Aufdecken des privaten Schlüssels harmlos. Aber warum sollte er dann ein solches Schlüsselpaar haben ?

  2. Möglicherweise befinden sich alle Server, mit denen er eine Verbindung mit Authentifizierung mit privatem Schlüssel herstellt, in einem privaten Netzwerk mit nur nicht feindlichen Benutzern und einer starken Isolation von der Außenwelt.

  3. Es ist denkbar, dass der private Schlüssel durch ein Passwort (oder "Passphrase" in der SSH-Terminologie) geschützt ist, was bedeutet, dass er tatsächlich mit einem vom Passwort abgeleiteten Schlüssel verschlüsselt ist. und Ihr Freund hat großes Vertrauen in die Stärke seines Passworts.

Beachten Sie, dass sich die Angreifer auch dann im Namen Ihres Freundes (der bereits ein ist) bei diesen Servern anmelden können, wenn der private Schlüssel ungeschützt ist (oder durch ein erratenes Kennwort geschützt ist) und Zugriff auf einige von Angreifern erreichbare Server gewährt großes Problem). Dies gewährt Angreifern NICHT die Befugnis, einen Man-in-the-Middle-Angriff auszuführen (MitM ist ein doppelter Identitätswechsel, daher muss ein MitM-Angreifer die privaten Schlüssel sowohl auf dem Client als auch auf dem Server kennen). Sie können weder vergangene noch zukünftige Sitzungen, die sie belauschen, entschlüsseln oder Daten laufender Sitzungen ändern (insbesondere werden die asymmetrischen Schlüssel in SSH zur Authentifizierung verwendet, aber der Schlüsselaustausch verwendet Diffie-Hellman ).

61
Tom Leek

- Authentifizierung/Zugriffskontrolle

Personen, die über seine Anmeldeinformationen verfügen, können sich möglicherweise bei Systemen anmelden, die sich als er ausgeben.

- Nicht-Zurückweisung

Andere können Nachrichten als er signieren, und er kann das Senden nicht verweigern.

- Vertraulichkeit

Alle seine privaten Mitteilungen können entschlüsselt und durchgesickert sein.

- Integrität

Vorherige Dokumente können bereits neu signiert/gehasht werden und sind nicht mehr ganzzahlig wie in der letzten Version vor dem Vorfall.

Lange Rede, kurzer Sinn - er muss es so schnell wie möglich widerrufen und ein neues bekommen.

22
user69377

Private SSH-Schlüssel werden normalerweise (standardmäßig) mit einer starken symmetrischen Verschlüsselung verschlüsselt. Unter bestimmten Umständen (natürlich nicht in der Produktion) kann es sinnvoll sein, diese Schlüssel an einem zugänglichen gemeinsamen Ort zu haben, um die Bedienung zu vereinfachen. Dies reduziert die Stärke des Schlüssels kaum auf die Stärke des Kennworts, mit dem er verschlüsselt ist. Dies kann je nach Verwendungsmuster der oben genannten Schlüssel und Server, zu denen sie gehören, tolerierbar sein.

Musste hier nur den Anwalt des Teufels spielen.;)

0
oakad