it-swarm.com.de

SSH-Schlüsseltyp, rsa, dsa, ecdsa, gibt es einfache Antworten, für die Sie wann wählen können?

Als jemand, der wenig über Kryptographie weiß, frage ich mich, welche Wahl ich beim Erstellen von SSH-Schlüsseln treffe.

ssh-keygen -t type, wobei der Typ entweder dsa, rsa und ecdsa ist.

Googeln kann einige Informationen über Unterschiede zwischen den Typen geben, aber nichts aussagekräftiges. Meine Frage ist also, gibt es "einfache" Antworten für Entwickler/Systemadministratoren mit geringen Kryptografiekenntnissen, wann sie welchen Schlüsseltyp auswählen sollen?

Ich hoffe auf eine Antwort im Stil "Verwenden Sie DSA für X und Y, RSA für Z und ECDSA für alles andere", aber mir ist auch klar, dass solche einfachen Antworten möglicherweise nicht verfügbar sind.

164
user50849

In der Praxis funktioniert ein RSA-Schlüssel überall. Die ECDSA-Unterstützung ist neuer, sodass einige alte Clients oder Server möglicherweise Probleme mit ECDSA-Schlüsseln haben. Ein DSA-Schlüssel, der gemäß dem SSH-Standard ( RFC 4251 und nachfolgend) überall verwendet wurde. Dies wurde jedoch kürzlich geändert: OpenSSH 7.0 und höher akzeptieren standardmäßig keine DSA-Schlüssel mehr.

ECDSA ist rechnerisch leichter, aber Sie benötigen einen wirklich kleinen Client oder Server (z. B. 50 MHz Embedded ARM Prozessor)), um den Unterschied festzustellen.

Derzeit gibt es keinen sicherheitsrelevanten Grund, einen Typ einem anderen vorzuziehen, vorausgesetzt, die Schlüssel sind groß genug (2048 Bit für RSA oder DSA, 256 Bit) für ECDSA); Die Schlüsselgröße wird mit dem Parameter -b angegeben. Einige ssh-keygen - Versionen lehnen jedoch möglicherweise DSA-Schlüssel mit einer anderen Größe als 1024 Bit ab, was derzeit nicht unterbrochen ist, aber möglicherweise nicht so robust ist, wie es gewünscht wäre. Wenn Sie sich also einer leichten Paranoia hingeben, bevorzugen Sie möglicherweise RSA.

Um es zusammenzufassen, machen Sie ssh-keygen -t rsa -b 2048 Und Sie werden glücklich sein.

127
Thomas Pornin

Wie Gilles sagt, ist DSA riskant, denn wenn Sie Signaturen auf einer Box mit einem schlechten RNG erstellen (und die Verwendung Ihres Schlüssels mit einem SSH-Client zum Anmelden effektiv Signaturen erstellt), kann Ihr Schlüssel kompromittiert werden. AIUI dies machte Debian im Grunde DSA aufgeben für Schlüssel, die in ihrer Infrastruktur im Lichte des Fiaskos des Debian OpenSSL-Zufallszahlengenerators verwendet wurden.

http://meyering.net/nuke-your-DSA-keys/

ECDSA ist relativ neu, nach einigen schnellen Suchanfragen scheint es in 5.7 eingeführt worden zu sein. Die meisten dieser Systeme sind nicht unterstützt und sollten wahrscheinlich migriert werden, aber wir alle wissen, dass dies manchmal nicht der Fall ist. Zum Beispiel Debian Squeeze und Ubuntu lucid. ECDSA hat den Vorteil, dass ein Schlüssel bei gleicher (vermuteter) Sicherheit viel kleiner sein kann als ein RSA- oder DSA-Schlüssel. Leider teilt es den Nachteil von DSA, empfindlich gegenüber Generatoren für schlechte Zufallszahlen zu sein. Es gibt auch Bedenken, dass die traditionell verwendeten elliptischen Kurven möglicherweise hinter der Tür stehen.

ED25519 ist eine noch neuere Option, die von openssh 6.5 eingeführt wurde. Es ist eine Variante des ECDSA-Algorithmus, löst jedoch das Problem des Zufallszahlengenerators und verwendet eine Kurve "Nichts im Ärmel". Auf lange Sicht wird es wahrscheinlich die beste Option sein, aber derzeit gibt es noch unterstützte Systeme, die nicht über genügend neues OpenSh verfügen.

Daher ist IMO (mit einem 2048- oder 4096-Bit-Schlüssel, je nachdem, wie paranoid Sie sind) immer noch die vernünftigste Wahl für den allgemeinen Gebrauch.

Bearbeiten: Aktualisierung auf die aktuelle Situation ab März 2017.

25
Peter Green

DSA und ECDSA haben Schlüssel mit fester Länge und sind Standards der US-Regierung, was bedeutet, dass sie mehr über die Standards wissen als die breite Öffentlichkeit. RSA ist besser bekannt und Sie können damit längere Schlüssel generieren (Standard ist 2048 im Gegensatz zu DSAs fester Länge von 1024 Bit), daher ist es (wohl) besser zu verwenden.

9
GdD

Verwenden Sie RSA. Nicht aus Sicherheitsgründen, sondern aus Kompatibilitätsgründen.

Ich empfehle nicht, DSA-Schlüssel zu verwenden. Ab OpenSSH 7.0 unterstützt SSH standardmäßig keine DSA-Schlüssel mehr. Wie Versionshinweise für OpenSSH 7. , "ist die Unterstützung für ssh-dss Host- und Benutzerschlüssel zur Laufzeit standardmäßig deaktiviert". Daher verursacht die Verwendung von DSA-Schlüsseln (ssh-dss) nur Kopfschmerzen.

ECDSA-Schlüssel könnten besser sein, aber leider können ECDSA-Schlüssel auf einigen Plattformen auch Kompatibilitätsprobleme verursachen. Unter Fedora nimmt der gnome-keyring-daemon die ECDSA-SSH-Schlüssel nicht automatisch auf, sodass Sie nicht automatisch zur Eingabe eines Kennworts aufgefordert werden, um Ihren SSH-Schlüssel zu entsperren, wenn Sie versuchen, ihn unter Fedora zu verwenden.

RSA-Schlüssel sind völlig frei von diesen Kompatibilitätsproblemen. Sie werden am häufigsten verwendet und scheinen daher am besten unterstützt zu werden. Daher empfehle ich Ihnen, RSA-Schlüssel zu generieren, um sich später vor Ärger zu schützen.


Als redaktionelle Anmerkung ist die Entscheidung von OpenSSH, die DSA-Unterstützung zu deaktivieren, etwas rätselhaft: 1024-Bit-DSA-Schlüssel haben ngefähr die gleiche Sicherheit wie 1024-Bit-RSA-Schlüssel, daher ist nicht klar, warum OpenSSH die Unterstützung für 1024 deaktiviert hat -bit DSA-Schlüssel, aber weiterhin Unterstützung für 1024-Bit-RSA-Schlüssel. (OpenSSH unterstützt weiterhin RSA. Es gibt eine spezielle Prüfung zum Deaktivieren von RSA-Schlüsseln mit 768 Bit oder weniger. Bei DSA werden jedoch nur alle DSA-Schlüssel unabhängig von der Länge deaktiviert.) OpenSSH unterstützt auch DSA-Schlüssel, die länger als sind 1024 Bit lang; Es ist nicht klar, warum die Unterstützung für sie deaktiviert wurde. Na ja, so geht es.

8
D.W.