Ist SSH Key Exchange sicherer als die Kennwortauthentifizierung?


9

Remotebenutzer stellen über das Internet über SSH eine Verbindung zu mehreren Diensten in unserem Hauptbüro her. Das SSH-Passwort wird mit dem LAN-A / D-Konto synchronisiert.

Wäre es sicherer, wenn Benutzer eine Kopie eines SSH-Schlüssels mit einer CD oder einem Blatt Papier nach Hause bringen, als wenn Benutzer ihr Kennwort eingeben? Oder sollte ich beides benötigen?

Meine Frage könnte wahrscheinlich wie folgt umformuliert werden: Gibt es eine Sicherheitslücke im Kennwortauthentifizierungsprotokoll von SSH?

Es ist diese Botschaft, die mich zweifeln lässt:

The authenticity of host 'xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx)' can't be established.
RSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:.
Are you sure you want to continue connecting (yes/no)?

Antworten:


22

Die angezeigte Nachricht ist ein separates Problem. Sie werden aufgefordert, zu bestätigen, dass der Host, zu dem Sie eine Verbindung herstellen, wirklich der ist, den Sie erwarten. Vom Server können Sie den Fingerabdruck durch Ausführen abrufen ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub. Wenn Sie dann zum ersten Mal eine Remoteverbindung herstellen, können Sie sicherstellen, dass die Fingerabdrücke übereinstimmen.

Host-Schlüssel, die hier in Aktion zu sehen sind, befassen sich mit dem Problem der Man-in-the-Middle- Angriffe - möglicherweise wurde DNS untergraben, und Sie stellen eine Verbindung zu einem Computer eines Mitbewerbers anstelle Ihres eigenen her. Dieser Computer sammelt Ihre Anmeldeinformationen und leitet Ihre Verbindung transparent an den realen Server weiter. Dabei werden Ihre Informationen gestohlen, ohne dass Sie es wissen. Wenn Sie sicherstellen, dass der Hostschlüssel übereinstimmt, wird dies verhindert, es sei denn, der Angreifer hat den öffentlichen Schlüssel Ihres Servers tatsächlich gestohlen.

Es bleibt jedoch ein Problem - woher wissen Sie, welcher Schlüssel richtig ist? Nach der ersten Verbindung wird der öffentliche Schlüssel in Ihrer ~/.ssh/known_hostsDatei gespeichert , sodass nachfolgende Verbindungen in Ordnung sind. Aber beim ersten Mal benötigen Sie entweder eine Out-of-Band-Methode, um den Fingerabdruck zu erhalten, oder Sie folgen dem "TOFU" -Modell: Vertrauen bei der ersten Verwendung.

Aber nichts davon hat etwas mit Passwörtern oder Schlüsseln zu tun, außer dass sowohl Schlüssel als auch Passwörter durch diesen Angriff gestohlen werden könnten - in gewissem Sinne ist es die Sicherheitslücke, nach der Sie fragen.

Es gibt (mindestens) drei Gründe, warum Passwörter schlechter sind als Schlüssel:

  1. Sie können brutal gezwungen werden. Ein typisches vom Benutzer ausgewähltes 8-stelliges Passwort weist etwa 30 Bit Vermutungsentropie auf. Ein öffentliches / privates SSH-Schlüsselpaar ist 1024 Bit oder größer. Es ist praktisch unmöglich, einen SSH-Schlüssel brutal zu erzwingen, aber das automatische Erraten von Passwörtern geschieht ständig.
  2. Sie können dumm sein. Benutzer wählen routinemäßig schreckliche Passwörter aus, selbst wenn Einschränkungen bestehen, und sie neigen dazu, an mehreren Stellen härtere Passwörter zu verwenden. Dies erleichtert offensichtlich Angriffe.
  3. Passwörter können aus der Ferne gestohlen werden. Wenn Sie SSH verwenden, wird das Kennwort auf dem Kabel verschlüsselt. In kompromittierten Systemen wird der SSH-Server jedoch häufig durch ein System ersetzt, das alle Kennwörter protokolliert. Bei Schlüsseln bleibt der private Schlüssel auf dem lokalen System und wird überhaupt nicht gesendet. Daher kann er nicht gestohlen werden, ohne den Client-Computer tatsächlich zu gefährden.

Darüber hinaus bieten SSH-Schlüssel Komfort bei der Verwendung mit so etwas wie ssh-agent- Sie können problemlos eine Verbindung herstellen, ohne sich jedes Mal neu zu authentifizieren, und gleichzeitig ein angemessenes Maß an Sicherheit gewährleisten.

Es ist kein wesentlicher Vorteil, nach beidem zu fragen, da jemand, der genügend Zugriff hat, um den privaten Schlüssel zu stehlen, auch ziemlich leicht das Passwort des Benutzers stehlen kann. Wenn Sie mehr Sicherheit benötigen, sollten Sie ein Zwei-Faktor-Authentifizierungssystem wie RSA SecurID oder WiKID in Betracht ziehen .


Gute Antwort. Genau das, wonach ich gesucht habe. Vielen Dank!
srmark

zu Nummer 3) Wenn Sie sich bei einem bereits komprimierten Server anmelden ... warum sollte jemand Ihr Passwort wollen? Der einzige Grund, an den ich denken kann, ist, wenn Sie überall das gleiche Passwort verwenden.
Sirex

Sirex - richtig; Sie stehlen Ihr Passwort und verwenden es auf anderen Systemen. Beachten Sie in der Frage, dass die Passwörter als "LAN A / D" verwendet werden. Sie stehlen also Ihr Passwort vom SSH-Anmeldeserver und haben dann auch Zugriff auf den Windows-Server. Außerdem müssen Sie jetzt, wenn das System kompromittiert wird, die Feuerübung "Okay, jeder ändert Ihr Passwort erneut" durchlaufen.
Mattdm

Auch kann , wie in 2 Nummer angegeben, die Benutzer sind überall das gleiche Passwort. Seufzer.
Mattdm

Nieder mit lästigen Benutzern! :(
Sirex

1

Was Sie wirklich fragen, ist "ist ein Faktor besser als ein anderer", das Thema ist die Multi-Faktor-Authentifizierung und Sie wären wirklich gut beraten, sich mit dem Thema zu befassen.

In der Regel ist ein "Faktor" etwas, das Sie kennen (Passwort), etwas, das Sie haben (SSH-Datei oder Schlüssel-Swipe-Karte) oder etwas, das Sie sind (Fingerabdruck).

Man ist nicht besser als ein anderer an sich, sie sind kostenlos. Der Verlust einer CD mit der Schlüsseldatei ist genauso schlimm wie die Offenlegung Ihres Passworts, wenn dies alles ist, was Sie benötigen. Für sichere Umgebungen ist die Zwei-Faktor-Authentifizierung üblich.


Ja, ich verstehe, was du sagst. In diesem Fall versuche ich jedoch nur herauszufinden, ob die Passwortauthentifizierung mit so etwas wie einem Mann in der Mitte gehackt werden kann.
srmark

für ssh als spezifisches Beispiel nein, da der Abschnitt zur Kennwortvergabe ebenfalls verschlüsselt ist und sich die Schlüssel während der Sitzung ändern (30 Sekunden, glaube ich). Das ist jedoch kein Spiegelbild von Passwort gegen Passkey
Sirex
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.