Tricks für wirklich sichere SSH-Verbindungen

905
Guilherme Vieira

Ich weiß, dass SSH sicher ist, solange Sie keine MITM-Attacke erleiden. Ich möchte jedoch wissen, ob es eine Möglichkeit gibt, SSH auch unter solchen Umständen zu 100% sicher zu machen. Stellen Sie fest, dass Sie erschöpft sind und die Verbindung trennen, bevor vertrauliche Informationen vorhanden sind offen gelegt oder zumindest nicht unmöglich gemacht, sondern "schwieriger" für den Angreifer, tatsächlich Daten zu lesen / schreiben (möglicherweise gibt es eine Möglichkeit, die Daten zu verstümmeln, sodass sie keinen Sinn machen oder etwas?).

Ich glaube du hast was ich will.

Wenn Sie zum Beispiel die Verbindung ablehnen, falls der Fingerabdruck nicht der von Ihnen erwartete ist, funktioniert MITM noch?

Ich werde versuchen, diese Frage zu aktualisieren, wenn mir Ideen einfallen.

2
Sie können MitM-Angriffe besiegen, indem Sie Schlüssel vorab freigeben. CarlF vor 13 Jahren 0
Ja, ich denke das sollte funktionieren. Guilherme Vieira vor 13 Jahren 0

2 Antworten auf die Frage

5
grawity

entdecke, dass du geschnuppert wirst

Genau dies schützt SSH vor. Solange Sie den Host-Schlüssel sorgfältig überprüfen, spielt es keine Rolle, ob jemand Ihren Datenverkehr liest: Es ist alles verschlüsselt.

Unterbrechen der Verbindung, bevor sensible Informationen offengelegt werden

Wieder wird Standard-SSH in Ordnung sein. Die Überprüfung des Host-Schlüssels ist eines der ersten Schritte beim Aufbau einer SSH-Verbindung. Wenn Sie es abbrechen, wird die Verbindung sofort geschlossen, ohne dass Authentifizierungsdaten übertragen werden.

Wenn Sie zum Beispiel die Verbindung ablehnen, falls der Fingerabdruck nicht der von Ihnen erwartete ist, funktioniert MITM noch?

Der Angreifer erhält keine "privaten" SSH-Daten, wenn Sie das meinen. Siehe oben - Die Überprüfung des Host-Schlüssels ist eines der ersten Dinge, die durchgeführt werden. Es wird nichts weiter gesendet, bis der Server überprüft wurde.

Vielleicht gibt es eine Möglichkeit, die Daten zu verstümmeln, damit es keinen Sinn macht oder so etwas?

Es heißt "Verschlüsselung" und ist zufällig ein zentraler Bestandteil von SSH. :) Der Angreifer kann nichts lesen, es sei denn, Sie akzeptieren den Hostkey anstelle des echten Schlüssels. Ebenso macht die Verschlüsselung zusammen mit der Integritätsprüfung (mit HMAC) das Einfügen von Paketen unmöglich.

Ich gebe zu, dass ich kein Kryptograf bin. IMHO, wenn Sie den Fingerabdruck des Host-Schlüssels sorgfältig prüfen, ist SSHv2 so sicher, wie es nur geht.

  • Wenn es nicht sicher wäre, wäre es behoben / ersetzt / aktualisiert worden. Dies ist einmal geschehen: SSH v1 wurde durch SSH v2 ersetzt.

  • Dies bedeutet, dass Sie SSH v1 sowohl auf dem Server als auch auf dem Client deaktivieren müssen .

    SSH-Version 1 ist sehr unsicher. Auch wenn die meisten Clients für die Verwendung von SSHv2 konfiguriert sind, werden sie trotzdem auf Version 1 zurückgesetzt, wenn ein Server Version 2 nicht anbietet. Dies bietet eine Gelegenheit für einen MITM-Angriff ... Obwohl ich mich nicht an die Details erinnere, hat dies etwas damit zu tun, dass der Angreifer einen v1-Schlüssel mit einem sehr ähnlichen Fingerabdruck generiert.

    Fügen Sie für OpenSSH Protocol 2Ihre Konfigurationsdatei ein.

  • Es besteht eine sehr geringe Möglichkeit, dass einer der von SSH verwendeten Algorithmen fehlerhaft ist. Wenn es jemandem gelingt, RSA oder DH zu brechen, wird die Welt größere Probleme haben als die Sicherheit Ihres Servers ... (Außerdem gibt es alternative Algorithmen.)

OpenSSH v5.8 hat übrigens von DH und DSA zu seinen primären Algorithmen ECDH und ECDSA gewechselt (jeweils für Schlüsselaustausch und Hostschlüssel).

Um nur ein bisschen Ihrer Antwort zu klären, wird der Host-Schlüssel dem Server vom Client angezeigt *, bevor Sie * etwas außerhalb des anfänglichen Handshakes senden - dh kein Benutzername, kein Kennwort, kein Schlüssel, nichts wurde gesendet. Diesen Teil haben Sie gesagt, aber ich möchte Folgendes klarstellen: Der Host-Schlüssel ist * unmöglich zu fälschen *, ohne dass zuerst der private Schlüssel des Servers abgefragt wurde. Dies erfordert zunächst den Zugriff auf ein privilegiertes Konto (z. B. root) auf dem Server. Verwenden Sie keine schwachen Kennwörter (besser, verwenden Sie statt der Kennwörter Schlüssel), und Sie sollten in Ordnung sein, solange Sie den Host-Schlüssel überprüfen. Kromey vor 13 Jahren 1
@Kromey: Richtig, aber es ist möglich, verschiedene Schlüssel mit sehr ähnlich aussehenden Fingerabdrücken zu erstellen. Siehe [Fuzzy Fingerprints Project] (http://freeworld.thc.org/thc-ffp/). grawity vor 13 Jahren 0
@grawity Richtig, aber "gleich aussehend" ist nicht "gleich", und jeder einzelne SSH-Client, den ich kenne, speichert den Host-Schlüssel und vergleicht ihn für eine * exakte Übereinstimmung erst später *. Er beschwert sich laut oder weigert sich überhaupt, eine Verbindung herzustellen sogar ein Byte ist aus. Solange Sie den Schlüssel bei der ursprünglichen Verbindung richtig überprüfen, sind Sie Gold. Kromey vor 13 Jahren 1
"Exakte Übereinstimmung" beinhaltet den Schlüsselalgorithmus und die Protokollversion, die ebenfalls sorgfältig geprüft werden müssen. Wenn auf dem Client der RSA-Schlüssel gespeichert ist, der Server jedoch nur DSA bereitstellt, wird bei einigen Clients nur ein Bestätigungsdialogfeld angezeigt. (Neueste OpenSSH geht das viel besser.) grawity vor 13 Jahren 0
Okay, wenn ich also einen Fingerabdruck bekomme, der anders ist als ich erwartet hatte, habe ich nichts zu tun, aber keine Verbindung herzustellen. Wenn es möglich wäre, wäre es Teil von SSH, richtig? Guilherme Vieira vor 13 Jahren 0
@ n2liquid: Richtig. grawity vor 13 Jahren 0
-1
w.pasman

SSH ist NICHT in Ordnung, sie neigt zum Man-in-the-Middle-Angriff.

Microsoft führt einen solchen "Angriff" auf Ihre Verbindung durch, wenn sich zwischen Ihnen und dem Server, den Sie erreichen möchten, eine Forefront TMG-Firewall befindet. Und dazu gehört das Spoofing von SSH-Zertifikaten.

Kann es die Zertifikate * mit identischen Fingerabdrücken * als die Original-Zertifikate fälschen? grawity vor 11 Jahren 3

Verwandte Probleme