Frage:
Ist die Verwendung eines öffentlichen Schlüssels zum Anmelden bei SSH besser als das Speichern eines Kennworts?
Nick T
2011-05-17 19:16:44 UTC
view on stackexchange narkive permalink

Die Verwendung eines öffentlichen / privaten Schlüsselpaars ist für die Anmeldung bei frequentierten Hosts recht praktisch. Wenn ich jedoch ein Schlüsselpaar ohne Kennwort verwende, ist das sicherer (oder weniger sicher) als ein Kennwort? Die Sicherheit meiner privaten Schlüsseldatei ist von größter Bedeutung, aber sagen wir, meine magische private Schlüsseldatei war nur eine Liste von Passwörtern für verschiedene Hosts. Gibt es einen Unterschied?

Crackable Bits eines SSH-Schlüssels sind wahrscheinlich drastisch höher als alles, was Sie für ein Passwort verwenden würden.
Warum ein Schlüsselpaar ohne Passwort? Warum nicht ein Passwort für Ihren privaten Schlüssel verwenden und ssh-agent verwenden, um die Sicherheit und den Komfort zu verbessern?
Sie können auch die Verwendung der S / KEY-Authentifizierung prüfen.
Siehe auch http://security.stackexchange.com/questions/69407/why-is-using-ssh-key-more-secure-than-using-passwords
Die Antwort auf https://security.stackexchange.com/questions/69407/why-is-using-an-ssh-key-more-secure-than-using-passwords ist IMO etwas besser verdaulich.Aber [@john's answer] (https://security.stackexchange.com/a/3898/6499) ist wahrscheinlich umfassender und sollte zum besseren Verständnis auch gelesen werden.
Sechs antworten:
#1
+86
john
2011-05-17 21:26:31 UTC
view on stackexchange narkive permalink

Meine Antwort lautet, dass die Verwendung von Paaren mit öffentlichem Schlüssel viel klüger ist als die Verwendung von Kennwörtern oder Listen von Kennwörtern. Ich werde mich auf Dinge konzentrieren, die nicht allgemein über verschiedene Formen der SSH-Authentifizierung bekannt sind, und ich sehe keine anderen Antworten, die sie erwähnen.

Zunächst müssen Sie diese Benutzerauthentifizierung verstehen ist ein anderer und separater Prozess als die Einrichtung des sicheren Kanals . Für Laien bedeutet dies, dass zunächst der öffentliche Schlüssel des Servers (falls akzeptiert!) Zum Aufbau des sicheren SSH-Kanals verwendet wird, indem die Aushandlung eines symmetrischen Schlüssels ermöglicht wird, der zum Schutz der verbleibenden Sitzung verwendet wird. Aktivieren Sie den Kanal Vertraulichkeit, Integritätsschutz und Serverauthentifizierung.

Nachdem der Kanal funktionsfähig und sicher ist, erfolgt die Authentifizierung des Benutzers. Die beiden üblichen Methoden hierfür sind die Verwendung eines Kennworts oder Die Kennwort-basierte Authentifizierung funktioniert wie Sie sich vorstellen können: Der Client sendet sein Kennwort über den sicheren Kanal, der Server überprüft, ob dies tatsächlich das Kennwort des jeweiligen Benutzers ist, und ermöglicht den Zugriff. Im Fall des öffentlichen Schlüssels haben wir eine ganz andere Situation. In diesem Fall ist auf dem Server der öffentliche Schlüssel des Benutzers gespeichert. Als Nächstes erstellt der Server einen zufälligen Wert (nonce), verschlüsselt ihn mit dem öffentlichen Schlüssel und sendet ihn an den Benutzer. Wenn der Benutzer derjenige ist, der sein soll, kann er die Herausforderung entschlüsseln und an den Server zurücksenden, der dann die Identität des Benutzers bestätigt. Es ist das klassische Challenge-Response-Modell . (In SSHv2 wird tatsächlich etwas anderes, aber konzeptionell Nahes verwendet)

Wie Sie sich vorstellen können, wird im ersten Fall das Kennwort tatsächlich an den Server gesendet (es sei denn, SSH würde eine Antwort auf die Kennwortabfrage verwenden), im zweiten Fall verlässt Ihr privater Schlüssel den Client nie. In dem imaginären Szenario, dass jemand den SSL-Verkehr abfängt und ihn entschlüsseln kann (mithilfe eines kompromittierten privaten Serverschlüssels oder wenn Sie beim Herstellen einer Verbindung zum Server einen falschen öffentlichen Schlüssel akzeptieren) oder Zugriff auf den Server oder Client hat, Ihr Kennwort wird bekannt sein - mit der Authentifizierung mit öffentlich-privatem Schlüssel und dem Challenge-Response-Modell fallen Ihre privaten Daten niemals in die Hand des Angreifers. Selbst wenn ein Server, mit dem Sie eine Verbindung herstellen, gefährdet ist, sind andere Server, für die Sie denselben Schlüssel verwenden, nicht betroffen !

Die Verwendung eines öffentlichen Schlüsselpaars bietet weitere Vorteile: Der private Schlüssel sollte nicht wie von Ihnen vorgeschlagen im Klartext auf Ihrem Client-PC gespeichert werden. Dadurch bleibt die private Schlüsseldatei natürlich offen, um Kompromisse einzugehen, wie dies eine unverschlüsselte Kennwortdatei tun würde, aber es ist einfacher, sie zu entschlüsseln (beim Anmelden) und den privaten Schlüssel zu verwenden. Es sollte verschlüsselt gespeichert werden und Sie müssen eine normalerweise lange Passphrase angeben, um es bei jeder Verwendung zu entschlüsseln.

Dies bedeutet natürlich, dass Sie die lange angeben müssen Passphrase jedes Mal, wenn Sie eine Verbindung zu einem Server herstellen, um Ihren privaten Schlüssel zu entsperren - Es gibt Möglichkeiten, dies zu umgehen. Sie können die Benutzerfreundlichkeit des Systems mithilfe eines Authentifizierungsagenten verbessern: Dies ist eine Software, die Ihre Schlüssel für die aktuelle Sitzung entsperrt, wenn Sie sich beispielsweise bei gnome anmelden oder wenn Sie sich zum ersten Mal bei Ihrem Client anmelden, damit Sie dies einfach tun können Geben Sie 'ssh remote-system-ip' ein und melden Sie sich an, ohne eine Passphrase anzugeben. Führen Sie dies mehrmals aus, bis Sie sich von Ihrer Sitzung abmelden.

Zusammenfassend lässt sich sagen, dass die Verwendung von öffentlichen Schlüsselpaaren wesentlich mehr Schutz bietet als die Verwendung von Kennwörtern oder Kennwortlisten, die erfasst werden können, wenn der Client der Server ist oder die sichere Sitzung ist gefährdet . Wenn keine Passphrase verwendet wird (was nicht passieren sollte), bieten öffentliche Schlüsselpaare dennoch Schutz vor gefährdeten Sitzungen und Servern.

Hmmm, ich habe gerade die Frage noch einmal gelesen und gesehen, dass speziell gefragt wird, ob es keine Passphrase für den privaten Schlüssel gibt - das habe ich beim Schreiben der Antwort nicht bemerkt. Natürlich gibt es immer noch die Möglichkeit, einen Agenten zu verwenden, daher ist es nicht sehr klug, keine Passphrase zu verwenden.
Die Antwort wurde bearbeitet, um die richtige Frage wiederzugeben (ohne Passphrasen).
Meine privaten Schlüssel können unter Ubuntu automatisch entschlüsselt werden, die Passwörter für sie werden mit meinem Login-Passwort verschlüsselt und Ubuntu entsperrt sie automatisch für mich, wenn ich mich anmelde. Dies ist wirklich das Beste aus beiden Welten, da ich den Komfort eines passwortlosen habe Schlüssel mit der Sicherheit eines passphrasierten (fast). Wenn Sie sich bei einem Hochsicherheits-Computersystem anmelden, ist dies möglicherweise nicht sicher genug, da Ihr Anmeldekennwort ziemlich leicht kompromittiert werden kann und somit die Passphasen für Ihre Schlüssel auch kompromittiert werden. Es ist jedoch viel besser als ein Schlüssel ohne Passphase.
Wenn "das Nichtverwenden einer Passphrase nicht klug ist", warum sagt dann die [OpenSSL-Dokumentation] (http://www.openssl.org/docs/HOWTO/keys.txt) ausdrücklich, dass "es eine gute Sache sein kann Vermeiden Sie es, es mit einem Passwort zu schützen "? (Soll ich das als unabhängige Frage stellen?)
Teile dieser Antwort sind etwas zu detailliert und verirren sich daher. Das Unterscheidungsmerkmal der Publickey-Authentifizierung in diesem Zusammenhang besteht darin, dass der Client etwas mit seinem privaten Schlüssel signiert und dabei kein Geheimnis preisgeben muss. Die SSH-2-Publickey-Authentifizierung verwendet kein Challenge-Response-Protokoll, wie in dieser Antwort beschrieben. Der Client signiert einen Wert, der von jeder Seite im Rahmen des symmetrischen Schlüsselvereinbarungsprozesses unabhängig abgeleitet wird. siehe RFC-4252, Abschnitt 7 (insbesondere die "Sitzungskennung"). Beide Seiten tragen dazu bei, und keiner kann es bestimmen.
Die Verwendung der Sitzungskennung bei der Authentifizierung mit öffentlichen Schlüsseln hat einen interessanten Effekt, auf den nicht oft hingewiesen wird: Sie bietet zusätzlichen Schutz vor einem Man-in-the-Middle-Angriff. Wenn der Angreifer den Schlüsselaustausch auf jeder Seite separat ausführt, sind die Sitzungskennungen (IDs) unterschiedlich. Der Server fordert eine Signatur über die ID für die Verbindung mit dem Angreifer an. Der Client erstellt jedoch nur eine Signatur über die ID auf seiner Seite. Der Angreifer hat keine Möglichkeit, sie zu zwingen, gleich zu sein, und keine Möglichkeit, den Client zu veranlassen, etwas anderes zu tun. Ein Challenge-Response-Protokoll würde dies nicht tun.
@RichardE.Silverman Vielleicht sollten Sie eine Bearbeitung vorschlagen. Es ist unwahrscheinlich, dass sich das Poster selbst bearbeitet, da er seit drei Jahren nicht mehr auf dieser Website ist.
#2
+16
Thomas Pornin
2011-05-17 19:27:18 UTC
view on stackexchange narkive permalink

Im Vergleich zu einer gespeicherten Liste von (langen und zufälligen) Passwörtern bietet ein gespeicherter privater SSH-Schlüssel dieselbe Sicherheit : Die Dinge sind sicher, solange Ihre private Datei privat bleibt.

Der private Schlüssel ist jedoch praktisch viel praktischer (im Moment unterstützen ihn die SSH-Clients sofort, im Gegensatz zu einer benutzerdefinierten Datei mit Kennwörtern, die Sie verwenden müssen mit einigen manuellen copy&paste) und theoretisch (Sie können denselben Schlüssel für jeden Host, zu dem Sie eine Verbindung herstellen möchten, wiederverwenden, während eine Liste von Kennwörtern linear mit der Anzahl der kontaktierten Hosts wächst, es sei denn, Sie verwenden dasselbe Kennwort für mehrere Hosts schlecht ).

Ich befürchte, dass einige Leser die Auswirkungen von „langen und zufälligen Passwörtern“ übersehen werden. Ein privater Schlüssel enthält viel mehr Entropie als ein realistisches Passwort (sagen wir mindestens 128 Bit Entropie, vorausgesetzt ein anständiges RNG; ein Passwort mit 10 ASCII-Zeichen hat ungefähr die Hälfte davon, viel weniger, wenn es einprägsam ist). Außerdem werden Passwörter viel häufiger als private Schlüssel wiederverwendet. In der Praxis bietet ein privater Schlüssel also Sicherheitsvorteile.
@Gilles-Asymmetrieschlüssel wie die in SSH verwendeten haben alle mindestens 1024 Entropiebits, nicht 128. Die asymmetrische Verschlüsselung erfordert jedoch auch mehr Entropie. 1024-Bit-Asymmetrie ist schwächer als 128-Bit-Symmetrieverschlüsselung. Wenn jemand versucht, einen SSH-Server brutal zu erzwingen, muss er dies "langsam" tun, um einen Denial-of-Service-Angriff zu vermeiden. Dies bedeutet, dass ein Passwort mit ~ 50 Entropiebits Hunderte von Millionen von Jahren benötigt, um es zu erraten. Gehen Sie schneller und der Server wird für die Dauer des Angriffs aus dem Internet gesprengt, und der Systemadministrator wird es bemerken / untersuchen.
Um ein 10-stelliges Passwort effektiv brutal zu erzwingen, benötigen Sie Hunderte von Billionen Vermutungen pro Sekunde, und es wird noch Wochen dauern. Kein Server kann irgendetwas aus der Ferne empfangen, das so vielen SSH-Anmeldeversuchen nahe kommt. Ein paar hundert Versuche pro Sekunde sind realistischer, was zu langsam ist, um effektiv zu sein, es sei denn, das Passwort ist schrecklich. Jeder, der diese Website liest, ist klug genug, ein gutes Passwort zu wählen.
@AbhiBeckert Ich denke, Sie verwechseln die Schlüsselgröße mit der Entropie. Das Brechen des Schlüssels oder Kennworts muss nicht immer ein Online-Angriff sein: Der Angreifer hat möglicherweise Zugriff auf den öffentlichen Schlüssel. Auf jeden Fall denke ich, dass Sie meinen Standpunkt völlig verfehlt haben: Die Entropie in einem Schlüsselpaar, abgesehen von [Bugs] (https://www.schneier.com/blog/archives/2008/05/random_number_b.html), ist immer viel größer als alle denkwürdigen Passwörter.
@Gilles und ich denken, Sie verpassen meinen Punkt, nämlich, dass niemand einprägsame Passwörter für einen Produktionsserver verwenden sollte. Passwörter sollten vollständige Zufallszahlen sein, die mit Zeichen codiert sind, die auf einer Tastatur eingegeben werden können.
#3
+13
Bruno
2011-05-17 20:16:45 UTC
view on stackexchange narkive permalink

Es hängt davon ab, welche Bedrohungen Sie in Betracht ziehen.

Der Hauptpunkt der Authentifizierung mit öffentlichen / privaten Schlüsseln besteht darin, Ihr Geheimnis nicht preiszugeben, auch nicht an die Partei, bei der Sie sich authentifizieren. Aus diesem Grund ist die Verwendung von Schlüsseln besser, da Sie Ihr Geheimnis niemals an Ihren Computer senden.

Wenn die Bedrohung jedoch lokal ist und Sie Ihre privaten Schlüssel nicht mit einem Kennwort schützen, Das Speichern einer Liste von Kennwörtern in klarer Form entspricht in etwa dem Speichern der privaten Schlüssel ohne Schutz.

Aus diesem Grund ist es hilfreich, Ihre privaten Schlüssel mit einem Kennwort zu schützen und Tools wie ssh-agent zu verwenden (zur Vereinfachung) ). Unter OSX kann dies auch in KeyChain integriert werden, sodass Sie möglicherweise nicht einmal den privaten Schlüssel entsperren müssen (auf Anwendungsebene, nur auf der Ebene des Sicherheitsdämons), um ihn über SSH (im Wesentlichen über KeyChain) verwenden zu können und Sicherheitsdämon kümmern sich um ssh-agent).

> Der Hauptpunkt der Authentifizierung mit öffentlichen / privaten Schlüsseln besteht darin, Ihr Geheimnis nicht preiszugeben, auch nicht an die Partei, bei der Sie sich authentifizieren. Aus diesem Grund ist die Verwendung von Schlüsseln besser, da Sie Ihr Geheimnis niemals außerhalb Ihres Computers senden. Wird die Authentifizierung mit dem Challenge-Passwort von SSH nicht unterstützt?
Willkommen bei Security.SE. Wie Sie vielleicht bemerkt haben, werden Ihre Antworten von verschiedenen Mitgliedern der Community abgelehnt. Wenn Sie die FAQ (Link oben auf der Seite) gut gelesen haben, erhalten Sie eine bessere Übersicht darüber, wie Sie in dieser Community posten können. Vielleicht möchten Sie sich auch mehr auf die neueren Fragen konzentrieren, anstatt alte mit hoch bewerteten, akzeptierten Antworten auszugraben.
... außerdem wäre Ihre Hinzufügung hier als Antwort besser geeignet gewesen, als Kommentar zu platzieren. In Bezug auf Ihre klärende Frage unterstützt SSH die Authentifizierung zur Kennwortabfrage nicht.
#4
+10
Karol J. Piczak
2011-05-17 20:12:57 UTC
view on stackexchange narkive permalink

Der Hauptunterschied zwischen der Verwendung eines privaten Schlüssels ohne Kennwort und der Verwendung eines Nur-Text-Kennworts für die SSH-Autorisierung besteht in der Autorisierung durch etwas, das Sie haben (Ihr privater Schlüssel) oder durch etwas, das Sie kennen (Ihr gespeichertes Passwort). Sie sind verschiedene Rassen, aber es ist schwer zu sagen, dass eine letztendlich besser oder sicherer ist.

Die Autorisierung durch etwas, das Sie haben ist für den Angreifer normalerweise schwieriger, sich aus dem zu replizieren blau - es ist einfacher, Ihr einfacheres Passwort zu erzwingen / zu erraten, als Ihren Schlüssel zu replizieren. Aber es hat einen großen Nachteil - jetzt ist es von größter Bedeutung, Ihren privaten Schlüssel wirklich geheim zu halten. Wenn Sie etwas verwenden, das nur Sie kennen (gespeichertes Passwort), sollte es einfacher sein, es so zu halten (zumindest theoretisch). Aber wenn Sie es sich merken müssen, verwenden Sie wahrscheinlich etwas, das nicht so komplex ist.

Sie müssen also entscheiden, was wahrscheinlicher ist - Ihr starker privater Schlüssel wird gestohlen oder nicht so stark erraten (oder erworben) auf andere Weise).

Hier gibt es eine Ausnahme: Wenn Sie in Ihrer Frage meinen, dass Sie wirklich lange, komplexe und zufällige Passwörter in Ihrer geheimen Datei speichern, anstatt einen privaten Schlüssel zu verwenden, dann gibt es eine wahrscheinlich kleiner Unterschied zwischen den beiden strike> noch ein Unterschied (ich habe den Teil verpasst, siehe @john 's Antwort für eine nette Zusammenfassung zu diesem ). In diesem Fall handelt es sich bei beiden um etwas, das Sie haben , halten Sie es geheim , aber fragen Sie sich dann - warum tun Sie das überhaupt, wenn private Schlüssel so entworfen wurden für? strike> sollten Sie in diesem Fall bei privaten Schlüsseln bleiben.

Beachten Sie auch, dass diese beiden Faktoren durch Kennwortschutz des privaten Schlüssels trivial kombiniert werden können. Jetzt brauchen Sie etwas, das Sie * kennen * (das Passwort), um an etwas zu gelangen, das Sie * haben * (den privaten Schlüssel).
#5
+8
sarnold
2011-06-13 06:10:02 UTC
view on stackexchange narkive permalink

In dem Dokument, auf das verwiesen wird, werden Kennwörter erläutert, die in einer SSH-Sitzung eingegeben wurden. Ich denke, es und Richards Kommentare sind es wert, hier zu bleiben, aber ich glaube nicht mehr an die Antwort selbst. (Ich bevorzuge immer noch öffentliche Schlüssel.)

Song, Wagner und Tian haben gezeigt, dass es möglich ist, die Suche nach Brute-Force-Passwörtern ungefähr 50 Mal zu beschleunigen Verwenden von Timing-Informationen aus ssh -Sitzungen . Noack hat seine Studie erneut besucht und festgestellt, dass SSH2 auch für Timing-Analysen anfällig ist.

Der Angriff geht von zwei Annahmen aus:

  • Der Passwort-Hash ist für Brute-Force-Cracking verfügbar.
  • Ein Angreifer kann genaue Zeitstempel für Pakete erhalten, die zwischen Hosts gesendet werden, oder auf andere Weise Zeitinformationen abrufen.

Öffentliche Schlüssel sind nicht nur bequemer, sondern auch sicherer gegen bestimmte Bedrohungen.

Dieser Kommentar ist irreführend, und der Autor hat möglicherweise die Arbeit von Song et al. Missverstanden. Dies gilt nur, wenn Sie Ihr Kennwort interaktiv über eine SSH-Verbindung eingeben: Wenn Sie sich beispielsweise mit SSH bei einem Remote-Host anmelden, führen Sie einen Befehl mit sudo aus, sodass Sie Ihr Kennwort für die sudo-Authentifizierung über die Verbindung eingeben müssen. Wenn Sie dies tun, zeigen die Inter-Packet-Timings Ihrer Tastenanschläge während der Eingabe des Kennworts Informationen zum Kennwort an. [Fortsetzung…]
Die Frage bezieht sich jedoch nicht auf "Eingabe Ihres Passworts über SSH", sondern auf "SSH-Passwortauthentifizierung", die völlig unabhängig ist. Wenn Sie sich über ein Kennwort bei einem SSH-Server authentifizieren (entweder mit den Benutzerauth-Methoden "Kennwort" oder "tastaturinteraktiv"), geben Sie Ihr Kennwort lokal ein - nicht über SSH. Das Passwort wird in einem einzigen Paket an den Server gesendet. Der Timing-Angriff spielt hier keine Rolle. Siehe: http://archive.oreilly.com/pub/a/linux/2001/11/08/ssh_keystroke.html
@RichardE.Silverman, danke. Ich habe meine Antwort so bearbeitet, dass ich das Papier falsch gelesen oder falsch erinnert habe. (Ich kann mich jetzt nicht erinnern, es war vor Ewigkeiten.)
#6
+2
martin
2011-06-12 20:11:15 UTC
view on stackexchange narkive permalink

Wenn Sie "Software" -Schlüssel verwenden (dh Schlüssel, die in Ihrem .ssh-Verzeichnis oder einem gleichwertigen Verzeichnis gespeichert sind), befinden Sie sich im Wesentlichen auf derselben Ebene wie das Speichern von Kennwörtern.

OpenSSH bietet jetzt fast anständige PKCS # 11-Unterstützung. Gleiches ist in KiTTY (einer PuTTY-Gabel) verfügbar. Um die Pubkey-Authentifizierung wirklich zu nutzen, sollten Sie sich für eine Smartcard entscheiden. Dann gibt es einen echten Unterschied zu Passwörtern. Eine durch ein Kennwort geschützte Software-Schlüsseldatei kann auf die gleiche Weise wie ein einfaches Kennwort repliziert werden, eine Smartcard dagegen nicht.

Wie in den anderen Antworten erwähnt, gibt es viele Szenarien, in denen pk auth ein sehr wirksamer Schutz ist. Sie sollten daher zumindest die Bedrohungsszenarien klären, die Sie ansprechen.
Wenn Ihr Host vom Gegner kompromittiert wird (außer verloren / gestohlen, was bedeutet, dass Sie gehackt / verwurzelt / verschlüsselt usw. sind), sind Ihre privaten Schlüssel, die durch ein Passwort geschützt sind, so gut wie einfache einfache Passwörter, die beschnüffelt werden - beide können kopiert und ohne verwendet werden Ihre Zustimmung. Das Klonen einer Smartcard hingegen hat sich für Sterbliche wie uns als "schwierig genug" erwiesen. Wenn Sie eine Smartcard zerstören, wird normalerweise der private Schlüssel zerstört. Wenn Sie eine Kopie einer Datei löschen, bedeutet dies nicht, dass "irgendwo" andere Kopien vorhanden sind.
Sicher. Sie ignorieren jedoch den Schutz, den Ihnen sogar die Software pk auth bietet, um Ihr Kennwort nicht an den Remote-Host (für eine mögliche Wiederverwendung auf anderen Hosts, auf denen Sie es wiederverwendet haben, wie es so viele Leute tun) oder an ein MITM wie andere zu verlieren darauf hingewiesen haben.
Vielleicht. Ich hoffe jedoch, dass ich auch auf Probleme mit der (nur passwortgeschützten) schlüsselbasierten Authentifizierung aufmerksam gemacht habe.


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...