WardtermSSH-Client
DE
Herunterladen

RSA oder ed25519: Welchen SSH-Schlüssel sollten Sie verwenden?

Verwenden Sie ed25519 für jeden neuen Schlüssel. Er bietet etwa die gleiche Sicherheit wie RSA 3072 bei einem viel kürzeren Schlüssel, und jede OpenSSH-Version seit 6.5 aus dem Jahr 2014 unterstützt ihn. Nutzen Sie RSA mit mindestens 3072 Bit nur, wenn ein Server oder Gerät ed25519 nicht akzeptiert. Ein vorhandener RSA-Schlüssel mit 3072 oder 4096 Bit ist weiterhin in Ordnung, es besteht also keine Eile, ihn zu ersetzen.

Einen guten Schlüssel, ohne Optionen zu studieren? Wardterm beginnt mit Ed25519, auf Wunsch mit Passphrase. Zeigen

Aktualisiert am . Schlüsselerzeugung, Größen und die Legacy-Optionen liefen mit OpenSSH 10.0 unter Debian 13, gegen einen Testserver, der auf den alten Algorithmus ssh-rsa beschränkt war.

Der Vergleich

Ed25519RSA 3072RSA 4096
Geschätzte SicherheitEtwa 128 Bit128 BitZwischen 128 und 192 Bit
Datei des öffentlichen Schlüssels92 Byte564 Byte736 Byte
Datei des privaten Schlüssels, ohne Passphrase399 Byte2590 Byte3369 Byte
Wahl der GrößeKeine, immer 256 BitMit -b festlegenMit -b festlegen
Voraussetzung auf der GegenseiteOpenSSH 6.5 oder neuerFast jeder SSH-ServerFast jeder SSH-Server

Die Dateigrößen stammen von Schlüsseln, die wir mit dem Kommentar you@laptop erzeugt haben. Die Sicherheitsschätzungen stammen aus RFC 8032 für ed25519 und aus NIST SP 800-57 für RSA.

Worauf es wirklich ankommt

  • Weniger Auswahl, weniger Fehler. Ein ed25519-Schlüssel hat eine einzige Größe, so kann niemand versehentlich einen schwachen erzeugen. ssh-keygen ignoriert -b bei diesem Typ: Wir haben 4096 verlangt und 256 bekommen.
  • Kurze öffentliche Schlüssel. Eine Zeile, die in eine Chatnachricht oder Konfigurationsdatei passt, ohne abgeschnitten zu werden.
  • Schutz der Datei. Ein Schlüssel ohne Passphrase auf einem gestohlenen Laptop ist ungeschützt, egal welchen Typs. Das zählt weit mehr als der Unterschied zwischen den beiden Algorithmen.

Wie Sie jeden Schlüssel samt Passphrase an einem Ort aufbewahren, zeigt die SSH-Schlüsselverwaltung mit verschlüsseltem Tresor.

Jeden Typ erzeugen

ssh-keygen -t ed25519 -C "you@laptop"
ssh-keygen -t rsa -b 4096 -C "you@laptop"

Ohne -b haben RSA-Schlüssel 3072 Bit, der Standard seit OpenSSH 8.0. Seit OpenSSH 9.5 erzeugt ssh-keygen ohne -t einen ed25519-Schlüssel. Die vollständigen Schritte stehen in ed25519-Schlüssel erzeugen.

RSA-Schlüsselgrößen

  • Unter 1024 Bit: ssh-keygen lehnt ab mit Invalid RSA key length: minimum is 1024 bits.
  • 1024 Bit: nicht verwenden. Er lässt sich noch erzeugen, aber ein Server mit höherem RequiredRSASize lehnt ihn ab. Diese Einstellung gibt es seit OpenSSH 9.1, ihr Standardwert ist 1024.
  • 2048 Bit: NIST bewertet das mit 112 Bit Sicherheit. Es funktioniert, ist aber das alte Minimum, ersetzen Sie ihn also bei der nächsten Schlüsselrotation.
  • 3072 oder 4096 Bit: Nehmen Sie eine dieser Größen, wenn Sie RSA brauchen.

Wann RSA noch die richtige Wahl ist

  • Ein Server läuft mit einem OpenSSH älter als 6.5.
  • Ein altes Netzwerkgerät, Appliance oder Embedded-System nennt in der Dokumentation nur RSA-Schlüssel.
  • Eine Compliance-Vorgabe oder ein System im FIPS-Modus schränkt die erlaubten Schlüsseltypen ein. Prüfen Sie die Liste Ihres Herstellers.

Sie können je einen Schlüssel beider Typen behalten und RSA nur für die Hosts verwenden, die es brauchen:

Host old-server
    IdentityFile ~/.ssh/id_rsa
    IdentitiesOnly yes

Verbindung zu alten Systemen

Ein RSA-Schlüssel ist nicht dasselbe wie die damit erzeugte Signatur. Seit OpenSSH 8.8 verwendet der Client die alte ssh-rsa-Signatur, die auf SHA-1 beruht, nicht mehr, außer Sie verlangen sie. Dieselbe Schlüsseldatei funktioniert weiterhin mit den neueren Signaturen rsa-sha2-256 und rsa-sha2-512, die OpenSSH seit 7.2 unterstützt.

Ein Server, der nur den alten Algorithmus kennt, liefert diesen Fehler:

Unable to negotiate with 203.0.113.10 port 22: no matching host key type found. Their offer: ssh-rsa

Schalten Sie den alten Algorithmus nur für diesen einen Host wieder ein, und nur wenn Sie ihn nicht aktualisieren können:

ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa user@old-server

Das schwächt die Verbindung, lassen Sie es also aus Host * heraus. Ein neuer RSA-Schlüssel hilft hier nicht, weil das Problem die Signatur ist und nicht der Schlüssel. Siehe auch no mutual signature supported und no matching key exchange.

DSA und ECDSA

DSA gibt es nicht mehr: OpenSSH 10.0 hat es entfernt, und ssh-keygen -t dsa antwortet jetzt mit unknown key type dsa. Ersetzen Sie jeden DSA-Schlüssel, den Sie noch haben. ECDSA funktioniert und wird breit unterstützt, bietet aber gegenüber ed25519 keinen Vorteil, es sei denn, ein System verlangt es.

Ihre vorhandenen Schlüssel prüfen

for f in ~/.ssh/*.pub; do ssh-keygen -lf "$f"; done

Die erste Zahl ist die Größe und das letzte Wort der Typ, zum Beispiel 3072 SHA256:... you@laptop (RSA).

Fragen

Ist RSA 4096 stärker als ed25519?

Auf dem Papier hat es eine etwas höhere Sicherheitsschätzung, aber beide liegen weit jenseits dessen, was heute angreifbar ist, es ist also kein Grund, es zu wählen. Das praktische Risiko ist der Diebstahl der privaten Schlüsseldatei, und dagegen hilft bei beiden Typen eine Passphrase.

Kann ich einen RSA-Schlüssel in ed25519 umwandeln?

Nein. Es sind verschiedene Schlüsselarten. Erzeugen Sie einen neuen ed25519-Schlüssel, tragen Sie seinen öffentlichen Schlüssel auf Ihren Servern ein, testen Sie die Anmeldung und entfernen Sie dann den alten öffentlichen Schlüssel.

Ändert ein Quantencomputer die Wahl?

Nein, nicht zwischen diesen beiden: Ein ausreichend großer Quantencomputer würde beide brechen. OpenSSH 10.6 aktiviert einen hybriden Post-Quanten-Schlüsseltyp, erzeugt mit ssh-keygen -t mldsa44-ed25519, aber beide Seiten brauchen 10.6 oder neuer. Zum Schlüsselaustausch siehe die Anleitung zur Post-Quanten-Warnung.

Quellen

Mehr zu Schlüssel und Anmeldung

Alle Anleitungen