☰

Generieren eines privaten+öffentlichen Schlüsselpaars für SSH: Unterschied zwischen ssh-keygen und openssl?

tag-icon • tag-icon ssh openssh openssl ssh-keys private-key
Generieren eines privaten+öffentlichen Schlüsselpaars für SSH: Unterschied zwischen ssh-keygen und openssl?

Ich möchte private und öffentliche Schlüsselpaare erstellen, die für die SSH-Authentifizierung verwendet werden sollen.

Ich kann den Unterschied zwischen Folgendem nicht erkennen:

openssl genrsa -out MyPrivateKey 4096
openssl rsa -in MyPrivateKey -pubout -out MyPublicKey

welches zunächst einen privaten RSA-Schlüssel erzeugt und daraus anschließend den öffentlichen Schlüssel ableitet, oder:

ssh-keygen -b 4096 -t rsa -f MyFancyKey

Dadurch wird ein privater RSA-Schlüssel in der Datei „MyFancyKey“ und der entsprechende öffentliche Schlüssel in „MyFancyKey.pub“ erstellt.

Die Struktur der privaten Schlüssel scheint ziemlich ähnlich zu sein, obwohl der erstellte Schlüssel opensslmit Folgendem beginnt:
-----BEGIN RSA PRIVATE KEY-----

Und das von ssh-keygenbeginnt mit:
-----BEGIN OPENSSH PRIVATE KEY-----

Gibt es einen grundlegenden Unterschied zwischen diesen beiden Schlüsselarten?

Anschließend die entsprechenden öffentlichen Schlüssel, die dieser hier opensslenthält:

-----BEGIN PUBLIC KEY-----
  ...base64 encoded...
-----BEGIN PUBLIC KEY-----

Während das von ssh-keygennur eine Zeile enthält:
ssh-rsa XXXXXX...base64 encoded...XXXXX [email protected]

Handelt es sich im Wesentlichen um dieselbe Art von Daten, nur in unterschiedlichem Format? Oder sind sie tatsächlich inkompatibel?

Ich versuche, vollständig zu verstehen, wie das alles in Bezug auf SSH funktioniert. Warum sind beispielsweise mein Benutzername, mein Computername und mein lokaler Netzwerkname in diesem Schlüssel enthalten? Soll er nicht normalerweise für den Zugriff auf SSH verwendet werden?andereComputer? Mit meinem Benutzernamen auf diesem Computer, nicht meinem eigenen.

Antwort1

Private Schlüssel

Gibt es einen grundlegenden Unterschied zwischen diesen beiden Schlüsselarten?

Nein, es sind im Wesentlichen dieselben Daten.

  • BEGIN RSA PRIVATE KEYsteht für das Schlüsselformat „PKCS#1“ oder „PEM“, das eine Base64-Kodierung einer ASN.1 DER-serialisierten Struktur ist. Es handelt sich um eine grundlegende ASN.1-Sequenz, die die RSA-Parameter enthält (N,t,D,P,Q, usw).

    Dieses Format stammt aus der E-Mail-Sicherheitsinitiative PEM, aus der später S/MIME wurde (daher die Verwendung von ASN.1 DER) und wurde allgemein für SSL/TLS sowie verschiedene generische RSA verwendet.

    Lange Zeit war es auch das Primärschlüsselformat von OpenSSH (da OpenSSH bereits den kryptografischen Code von OpenSSL verwendet, waren die Funktionen „Schlüssel laden“ und „Schlüssel schreiben“ ebenfalls praktischerweise verfügbar). Das bedeutet, dass Sie ssh-keygen -m PEMsolche Schlüssel generieren oder konvertieren können.

  • BEGIN PRIVATE KEYzeigt das Schlüsselformat „PKCS#8“ (unverschlüsselt) an; der Inhalt ist dem PEM-Format sehr ähnlich, wobei die gleichen RSA-Parameter in einer anderen Struktur verschachtelt sind, die anzeigt, dass es sich tatsächlich um einen RSA-Schlüssel handelt.

    PKCS#8 ist speziell als moderner Ersatz für das PEM-Format gedacht. Im Vergleich zu PEM trennt das PKCS#8-Format die „Nutzlast“ (Schlüsselalgorithmus, Verschlüsselung) sauberer vom äußeren Base64-Wrapper – alle Metadaten befinden sich jetzt innerhalb der Struktur, sodass sie für neue Schlüsseltypen leichter zu aktualisieren ist. Das neue Format unterstützt auch bessere Chiffren und KDFs für verschlüsselte Schlüssel.

    OpenSSH erkennt dieses Format auch (aufgrund der Verwendung von OpenSSL zum Laden von Schlüsseln) und ich denke, dass neuere Versionen es auch erstellen können.

  • BEGIN OPENSSH PRIVATE KEYist ein von OpenSSH für OpenSSH erfundenes Format und verwendet im Gegensatz zu den PEM/PKCS-Formaten die SSHv2-Paketserialisierung für seine Datenstrukturen (kein DER oder ASN.1 mehr).

    Ein Grund, warum OpenSSH dieses Format jetzt verwendet, besteht darin, dass es die Abhängigkeit von OpenSSL vollständig vermeiden und/oder neue Schlüsselalgorithmen hinzufügen kann, ohne darauf warten zu müssen, dass OpenSSL das Laden/Speichern dieser Schlüssel implementiert. Dies bedeutet auch, dass man warten muss, bis PKIX die ASN.1-OID und -Struktur für jeden neuen Algorithmus standardisiert (der ansonsten absolut nichts mit SSH zu tun hat).

    Beispielsweise dauerte es eine Weile, bis OpenSSL die volle Ed25519-Unterstützung erhielt. Während dieser Zeit konnte OpenSSH weder die libcrypto von OpenSSL für die eigentliche Mathematik noch zum Laden/Speichern von Ed25519-Schlüsseldateien verwenden – das war der Anlass für die Erstellung dieses Formats.

    Ein weiterer Vorteil des OpenSSH-Formats besteht darin, dass mit Passphrasen verschlüsselte Schlüssel bcrypt zur Ableitung des Verschlüsselungsschlüssels verwenden. Damals war das PEM-Format auf ein sehr schwaches (d. h. leicht mit Brute Force zu knackendes) KDF beschränkt, und selbst PKCS#8 unterstützt nur das etwas schlechtere PKBDF2.

  • PuTTY hat ein eigenes .ppkFormat, das größtenteils textbasiert ist.

    Der angebliche Vorteil liegt darin, dass keine separate .pub-Datei erforderlich ist, da nur die privaten Parameter selektiv verschlüsselt werden. Sowohl die früheren PKCS-Formate als auch das spätere OpenSSH-Format verschlüsseln alles oder nichts und benötigen daher die .pub-Datei, damit sie den Schlüssel anbieten können, bevor sie Sie zur Entsperrung nach der Passphrase fragen.

    Sie können /usr/bin/puttygenzwischen allen diesen Formaten konvertieren.

  • Java-Software verwendet möglicherweise das PKCS#12-Format (PFX), da es sich dabei um das native „Java-Keystore“-Format handelt, und manche Software verwendet möglicherweise sogar das sogenannte Standardformat SSH.COM.

Siehe auch:Dateiformat für öffentlichen OpenSSH-Schlüssel?

Öffentliche Schlüssel

Handelt es sich im Wesentlichen um dieselbe Art von Daten, nur in unterschiedlichem Format?

Ja, es sind im Wesentlichen dieselben Daten.

  • BEGIN PUBLIC KEYist, glaube ich, auch PKCS#8 – also gibt es innerhalb von Base64 eine DER-serialisierte ASN.1-Struktur, die es als RSA-Schlüssel identifiziert, gefolgt von Schlüsselparametern (N,t).

  • Das einzeilige Format ist teilweise OpenSSH-spezifisch, obwohl die zentralen Base64-codierten Daten genau dasselbe Format aufweisen, das im SSHv2-Protokoll selbst verwendet wird („on the wire“). Wie Sie vielleicht vermuten, verwenden die codierten Daten die SSHv2-Paketserialisierung – aber sie enthalten immer noch denselben RSANUndtWerte.

Siehe auch:Dateiformat für öffentlichen OpenSSH-Schlüssel?

Warum sind beispielsweise mein Benutzername, mein Computername und mein lokaler Netzwerkname in diesem Schlüssel

Es ist ein Kommentarum Ihnen zu helfen, diesen öffentlichen Schlüssel von anderen öffentlichen Schlüsseln zu unterscheiden, wenn Sie eine lange authorized_keysDatei haben.

verwandte Informationen