Ubuntu Manpage: ssh-keygen — Dienstewerkzeug für OpenSSH-Authentifizierungsschlüssel

BEZEICHNUNG

     ssh-keygen — Dienstewerkzeug für OpenSSH-Authentifizierungsschlüssel

ÜBERSICHT

     ssh-keygen [-q] [-a Runden] [-b Bits] [-C Kommentar] [-f Ausgabe-Schlüsseldatei] [-m Format]
     [-N neue_Passphrase] [-O Option] [-t dsa | ecdsa | ecdsa-sk | ed25519 | ed25519-sk | rsa]
     [-N neue_Passphrase] [-O Option] [-w Anbieter] [-Z Chiffre] ssh-keygen -p [-a Runden] [-f
     Schlüsseldatei] [-m Format] [-N neue_Passphrase] [-P alte_Passphrase] [-Z Chiffre]
     ssh-keygen -i [-f Eingabe-Schlüsseldatei] [-m Schlüsselformat] ssh-keygen -e [-f
     Eingabe-Schlüsseldatei] [-m Schlüsselformat] ssh-keygen -y [-f Eingabe-Schlüsseldatei]
     ssh-keygen -c [-a Runden] [-C Kommentar] [-f Schlüsseldatei] [-P Passphrase] ssh-keygen -l
     [-v] [-E Fingerabdruck-Hash] [-f Eingabe-Schlüsseldatei] ssh-keygen -B [-f
     Eingabe-Schlüsseldatei] ssh-keygen -D pkcs11 ssh-keygen -F Rechnername [-lv] [-f
     known_hosts-Datei] ssh-keygen -H [-f known_hosts-Datei] ssh-keygen -K [-a Runden] [-w
     Anbieter] ssh-keygen -R Rechnername [-f known_hosts-Datei] ssh-keygen -r Rechnername [-g]
     [-f Eingabe-Schlüsseldatei] ssh-keygen -M generate [-O Option] Ausgabedatei ssh-keygen -M
     Bildschirm [-f Eingabedatei] [-O Option] Ausgabedatei ssh-keygen -I Zertifikatsidentität -s
     CA-Schlüssel [-hU] [-D pkcs11-Anbieter] [-n Prinzipale] [-O Option] [-V
     Gültigkeitsintervall] [-z Seriennummer] file ... ssh-keygen -L [-f Eingabe-Schlüsseldatei]
     ssh-keygen -A [-a Runden] [-f Präfixpfad] ssh-keygen -k -f KRL-Datei [-u] [-s CA-öffentlich]
     [-z Versionsnummer] file ... ssh-keygen -Q [-l] -f KRL-Datei file ... ssh-keygen -Y
     find-principals [-O option] -s Signaturdatei -f erlaubte_Signierer-Datei ssh-keygen -Y
     match-principals -I Signierer-Identität -f erlaubte_Signierer-Datei ssh-keygen -Y
     check-novalidate [-O option] -n Namensraum -s Signaturdatei ssh-keygen -Y sign [-O Option]
     -f Schlüsseldatei -n Namensraum file ... ssh-keygen -Y verify [-O option] -f
     erlaubte_Signierer-Datei -I Signierer-Identität -n Namensraum -s Signaturdatei [-r
     Sperrdatei]

BESCHREIBUNG

ssh-keygen erstellt, verwaltet und wandelt Authentifizierungsschlüssel für ssh(1) um.
ssh-keygen kann Schlüssel für den Einsatz von SSH Protokollversion 2 erstellen.

Der Typ des zu erstellenden Schlüssels wird mit der Option -t angegeben. Falls ssh-keygen
ohne Argumente aufgerufen wird, erstellt es einen Ed25519-Schlüssel.

ssh-keygen wird auch zur Erstellung von Gruppen zum Einsatz im Diffie-Hellman-
Gruppenaustausch (DH-GEX) verwandt. Siehe den Abschnitt MODULI-ERSTELLUNG für Details.

Schließlich kann ssh-keygen zur Erstellung und Aktualisierung von Schlüsselsperrlisten
verwandt werden und prüfen, ob Schlüssel durch eine solche gesperrt wurden. Siehe den
Abschnitt SCHLÜSSELSPERRLISTEN für Details.

Normalerweise führt jeder Benutzer, der SSH mit asymmetrischer Schlüsselauthentifizierung
verwenden möchte, dieses einmal aus, um Authentifizierungsschlüssel in ~/.ssh/id_dsa,
~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519, ~/.ssh/id_ed25519_sk oder
~/.ssh/id_rsa zu erstellen. Zusätzlich kann der Systemadministrator dies verwenden, um
Rechnerschlüssel zu erstellen.

Normalerweise erstellt dieses Programm einen Schlüssel und fragt nach einer Datei, in der
der private Schlüssel gespeichert werden soll. Der öffentliche Schlüssel wird in einer Datei
mit dem gleichen Namen, aber angehängtem »pub« gespeichert. Das Programm fragt auch nach
einer Passphrase. Die Passphrase darf leer sein, um anzuzeigen, dass keine Passphrase
verwandt werden soll (Rechnerschlüssel müssen eine leere Passphrase haben) oder sie kann
eine Zeichenkette beliebiger Länge sein. Eine Passphrase ist ähnlich einem Passwort, sie
kann allerdings eine Phrase mit einer Reihe von Wörtern, Interpunktionszeichen, Zahlen,
Leerraum oder jeder von Ihnen gewünschten Zeichenkette enthalten. Gute Passphrasen sind
10-30 Zeichen lang, keine einfachen Sätze oder anderweitig leicht erratbar (englische
Ausdrücke haben nur 1-2 Bit an Entropie pro Zeichen und stellen sehr schlechte Passphrasen
dar) und enthalten eine Mischung von Groß- und Kleinbuchstaben, Zahlen und
nichtalphabetischen Zeichen. Die Passphrase kann später mit der Option -p geändert werden.

Es gibt keine Möglichkeit, eine verlorene Phassphrase wiederzuerlangen. Falls die Passphrase
verloren ist oder vergessen wurde, muss ein neuer Schlüssel erstellt und der entsprechende
öffentliche Schlüssel auf andere Maschinen kopiert werden.

Standardmäßig wird ssh-keygen Schlüssel in einem OpenSSH-spezifischen Format schreiben.
Dieses Format wird bevorzugt, da es besseren Schutz für abgelegte Schlüssel erlaubt sowie
ermöglicht, dass Schlüsselkommentare innerhalb der privaten Schlüsseldatei selbst
abgespeichert werden. Der Schlüsselkommentar ist zur Identifizierung des Schlüssels
nützlich. Der Kommentar wird bei der Erstellung des Schlüssel auf »Benutzer@Rechner«
initialisiert, kann aber später mit der Option -c geändert werden.

ssh-keygen kann weiterhin noch private Schlüssel im dem vorher verwandten PEM-Format mittels
des Schalters -m schreiben. Dies kann bei der Erstellung neuer Schlüssel und bei der
Umwandlung von Schlüsseln im Zusammenspiel mit dem Schalter -p (neue Passphrase) verwandt
werden.

Nachdem der Schlüssel erstellt wurde, wird ssh-keygen fragen, wo die Schlüssel zur
Aktivierung abgelegt werden sollen.

Folgende Optionen stehen zur Verfügung:

-A Einen Rechnerschlüssel für alle Vorgabe-Schlüsseltypen (RSA, ECDSA und ED25519)
erstellen, falls sie nicht bereits existieren. Die Rechnerschlüssel werden mit dem
Standard-Schlüsseldatei-Pfad, einer leeren Passphrase, den Vorgabe-Bits für den
Schlüssel-Typ und dem Standardkommentar erstellt. Falls auch -f angegeben wurde,
wird dessen Argument als Präfix für den Vorgabepfad für die entstehende Rechner-
Schlüsseldatei verwandt. Dies wird von Systemadministrationsskripten zur Erstellung
neuer Rechnerschlüssel verwandt.

-a Runden
Beim Speichern eines privaten Schlüssels gibt diese Option die Anzahl der verwandten
Runden der KDF (Schlüsselableitungsfunktionen, derzeit bcrypt_pbkdf(3)) an. Eine
höhere Anzahl führt zu einer langsameren Passphrasenbestätigung und erhöhter
Widerstandskraft gegen Knacken von Passwörtern mit roher Rechengewalt (falls die
Schlüssel gestohlen werden sollten). Die Vorgabe ist 16 Runden.

-B Zeigt die Kurzfassung der angegebenen privaten oder öffentlichen Schlüsseldatei im
bubblebabble-Format an.

-b Bits
Gibt die Anzahl der Bits in dem zu erstellenden Schlüssel an. Für RSA-Schlüssel ist
die minimale Größe 1024 Bit und die Vorgabe ist 3072 Bit. Im Allgemeinen wird 3072
Bit als ausreichend betrachtet. DSA-Schlüssel müssen genau 1024 Bit lang sein, wie
dies in FIPS 186-2 spezifiziert ist. Für ECDSA-Schlüssel bestimmt der Schalter -b
die Schlüssellänge durch Auswahl aus einer der drei elliptischen Kurvengrößen: 256,
384 oder 521 Bit. Wird versucht, eine andere als eine dieser drei Bitlängen für
ECDSA-Schlüssel anzugeben, so führt dies zu einem Fehlschlag. ECDSA-SK-, Ed25519-
und Ed25519-SK-Schlüssel haben eine feste Länge und der Schalter -b wird ignoriert.

-C Kommentar
Stellt einen neuen Kommentar bereit.

-c Erbittet die Änderung des Kommentars in den Dateien des öffentlichen und privaten
Schlüssels. Das Programm bittet um die Angabe der Datei mit den privaten Schlüsseln,
die Angabe der Passphrase (falls der Schlüssel eine hat) und um den neuen Kommentar.

-D pkcs11
Lädt die von der dynamischen PKCS#11-Bibliothek pkcs11 bereitgestellten öffentlichen
Schlüssel herunter. Wird dies zusammen mit -s verwandt, zeigt diese Option an, dass
sich in einem PKCS#11-Token ein CA-Schlüssel befindet (siehe den Abschnitt
ZERTIFIKATE für Details).

-E Fingerabdruck-Hash
Gibt den bei der Anzeige von Schlüssel-Fingerabdrücken zu verwendenden Hash-
Algorithmus an. Gültige Optionen sind »md5« und »sha256«. Die Vorgabe ist »sha256«.

-e Diese Option wird eine private und öffentliche OpenSSH-Schlüsseldatei einlesen und
auf der Standardausgabe einen öffentlichen Schlüssel in einem der in der Option -m
angegebenen Formate ausgeben. Das Vorgabe-Export-Format ist »RFC4716«. Diese Option
ermöglicht das Exportieren von OpenSSH-Schlüsseln zur Verwendung in anderen
Programmen, einschließlich mehrerer kommerzieller SSH-Implementierungen.

-F Rechnername | [Rechnername]:Port
Sucht in einer known_hosts -Datei nach dem angegebenen Rechnernamen (mit optionaler
Port-Nummer) und zeigt alle Treffer an. Diese Option ist zum Finden von gehashten
Rechnernamen oder -adressen nützlich und kann auch im Zusammenspiel mit der Option
-H verwandt werden, um gefundene Schlüssel in einem gehashten Format anzuzeigen.

-f Dateiname
Gibt den Namen der Schlüsseldatei an.

-g Verwendet bei der Ausgabe von Fingerabdruck-Ressourcen-Datensätzen mittels des
Befehls -r das generische DNS-Format.

-H Hasht eine known_hosts -Datei. Dies ersetzt alle Rechnernamen und Adressen durch
gehashten Darstellungen innerhalb der angegebenen Datei; der ursprüngliche Inhalt
wird in eine Datei mit der Endung ».old« verschoben. Diese Hashes können von ssh und
sshd normal verwandt werden, aber sie legen keine identifizierende Informationen
offen, sollte der Inhalt der Datei Dritten zugänglich werden. Diese Option verändert
bereits existierende gehashte Rechnernamen nicht und kann daher sicher bei Dateien
verwandt werden, die sowohl gehashte als auch nicht gehashte Dateinamen enthalten.

-h Beim Signieren eines Schlüssels wird ein Rechner- statt ein Benutzerzertifikat
erstellt. Lesen Sie den Abschnitt ZERTIFIKATE für Details.

-I Zertifikatsidentität
Gibt die Identität zum Signieren eines öffentlichen Schlüssels an. Lesen Sie den
Abschnitt ZERTIFIKATE für Details.

-i Diese Option liest eine unverschlüsselte private (oder öffentliche) Schlüsseldatei
in dem durch die Option -m angegebenen Format und gibt einen OpenSSH-kompatiblen
privaten (oder öffentlichen) Schlüssel auf die Standardausgabe aus. Diese Option
erlaubt das Importieren von Schlüsseln aus anderer Software, einschließlich einer
Reihe von kommerziellen SSH-Implementierungen. Das Standard-Importformat ist
»RFC4716«.

-K Lädt residente Schlüssel von einem FIDO-Authentifikator herunter. Die Dateien der
öffentlichen und privaten Schlüssel werden für jeden heruntergeladenen Schlüssel in
das aktuelle Verzeichnis geschrieben. Falls mehrere FIDO-Authentifikatoren verbunden
sind, werden die Schlüssel von dem ersten angefassten Authentifikator
heruntergeladen. Siehe den Abschnitt FIDO-AUTHENTIFIKATOR für weitere Informationen.

-k Erstellt eine KRL-Datei. In diesem Modus wird ssh-keygen eine KRL-Datei an dem Ort
erstellen, der mittels des Schalters -f angegeben ist. Diese Datei wird jede Datei
oder jedes Zertifikat sperren, das auf der Befehlszeile vorhanden ist. Zu sperrende
Schlüssel/Zertifikate können als Datei des öffentlichen Schlüssels oder in einem der
in Abschnitt SCHLÜSSELSPERRLISTEN beschriebenen Formate angegeben werden.

-L Gibt den Inhalt eines oder mehrerer Zertifikate aus.

-l Zeigt den Fingerabdruck der Datei des angegebenen öffentlichen Schlüssels. Für RSA-
und DSA-Schlüssel versucht ssh-keygen, die passende Datei des öffentlichen
Schlüssels zu finden und dessen Fingerabdruck auszugeben. Falls dies mit -v
kombiniert wird, wird eine künstlerische ASCII-Darstellung des Schlüssels mit dem
Fingerabdruck zusammen ausgegeben.

-M generate
Erstellt Kandidaten-Parameter für Diffie-Hellman-Gruppenaustausch (DH-GEX), die von
den »diffie-hellman-group-exchange-*«-Schlüsselaustauschmethoden verwandt werden.
Die durch diese Aktion erstellten Zahlen müssen vor der Verwendung weiterverarbeitet
werden. Siehe den Abschnitt MODULI ERSTELLUNG für weitere Informationen.

-M screen
Prüft Kandidatenparameter für den Diffie-Hellman-Gruppenaustausch. Dies akzeptiert
eine Liste von Kandidatenzahlen und testet, dass sie sichere (Sophie Germain)
Primzahlen mit akzeptierbaren Gruppenerstellern sind. Das Ergebnis dieser Aktion
kann zu der Datei /etc/ssh/moduli hinzugefügt werden. Siehe den Abschnitt MODULI
ERSTELLUNG für weitere Informationen.

-m Schlüsselformat
Gibt ein Schlüsselformat zur Schlüsselerstellung, die Konvertierungsoptionen für -i
(Import), -e (Export) und die Passphrasenänderungsaktion -p an. Letztere kann zur
Umwandlung zwischen den Formaten OpenSSH und PEM für private Schlüssel verwandt
werden. Die unterstützten Schlüsselformate sind »RFC4716« (RFC 4716/SSH2
öffentlicher oder privater Schlüssel), »PKCS8« (PKCS8 öffentlicher oder privater
Schlüssel) und »PEM« (PEM öffentlicher Schlüssel). Standardmäßig wird OpenSSH
neuerstellte private Schlüssel in seinem eigenen Format schreiben, bei der
Umwandlung öffentlicher Schlüssel zum Export ist aber das Vorgabeformat »RFC4716«.
Wird bei der Erstellung oder Aktualisierung eines unterstützten privaten
Schlüsseltyps ein »PEM«-Format gesetzt, dann führt dies dazu, dass der Schlüssel im
veralteten PEM-Format für private Schlüssel gespeichert wird.

-N neue_Passphrase
Stellt eine neue Passphrase bereit.

-n Prinzipale
Gibt einen oder mehrere Prinzipale (Benutzer oder Rechnernamen) an, die in einem
Zertifikat beim Signieren eines Schlüssels enthalten sein sollen. Es können mehrere,
durch Kommata getrennte Prinzipale angegeben werden. Lesen Sie den Abschnitt
ZERTIFIKATE für Details.

-O Option
Gibt eine Schlüssel-/Wert-Option an. Diese sind für die Aktion spezifisch, die
ssh-keygen ausführen soll.

Beim Signieren von Zertifikaten kann hier eine der im Abschnitt ZERTIFIKATE
aufgeführten Optionen angegeben werden.

Bei der Erstellung von Moduli oder der Prüfung kann eine der der im Abschnitt
MODULI-ERSTELLUNG aufgeführten Optionen angegeben werden.

Beim Erstellen von FIDO-Authentifikator-basierten Schlüsseln kann eine der im
Abschnitt FIDO-AUTHENTIFIKATOR aufgeführten Optionen angegeben werden.

Bei der Durchführung Signatur-bezogener Optionen mittels des Schalters -Y werden die
folgenden Optionen akzeptiert:

hashalg=Algorithmus
Wählt den zum Hashen der zu signierenden Nachrichten zu verwendende Hash-
Algorithmus aus. Gültige Algorithmen sind »sha256« und »sha512«. Die Vorgabe
ist »sha512«.

print-pubkey
Gibt nach der Signaturüberprüfung den vollständigen öffentlichen Schlüssel
auf die Standardausgabe aus.

verify-time=Zeitstempel
Legt eine Zeit fest, die bei der Validierung von Signaturen anstatt der
aktuellen Zeit verwandt werden soll. Die Zeit kann als Datum oder Zeit im
Format YYYYMMDD[Z] oder YYYYMMDDHHMM[SS][Z] angegeben werden. Daten und
Zeiten werden in der aktuellen Systemzeitzone interpretiert, außer das
Zeichen »Z« wird angehängt, das dazu führt, dass sie in der UTC-Zeitzone
interpretiert werden.

Bei der Erstellung von SSHFP-DNS-Datensätzen aus öffentlichen Schlüsseln mittels des
Schalters -r werden die folgenden Optionen akzeptiert:

hashalg=Algorithmus
Wählt einen beim Ausgeben von SSHFP-Datensätzen mittels des Schalters -D zu
verwendenden Hash-Algorithmus aus. Gültige Algorithmen sind »sha1« und
»sha256«. Standardmäßig werden beide ausgegeben.

Die Option -O kann mehrfach angegeben werden.

-P Passphrase
Stellt die (alte) Passphrase bereit.

-p Erbittet die Änderung der Passphrase einer Datei eines privaten Schlüssels, statt
einen neuen privaten Schlüssel zu erstellen. Das Programm wird nach der Datei, die
den privaten Schlüssel enthält, der alten Passphrase und zweimal nach der neuen
Passphrase fragen.

-Q Prüft, ob Schlüssel in einer KRL gesperrt wurden. Falls auch die Option -l angegeben
wurde, dann werden die Inhalte der KRL ausgegeben.

-q Bringt ssh-keygen zum Schweigen.

-R Rechnername | [Rechnername]:Port
Entfernt alle Schlüssel aus einer known_hosts -Datei, die zu dem angegebenen
Rechnernamen (mit optionaler Port-Nummer) gehören. Diese Option ist nützlich, um
gehashte Rechner zu löschen (siehe weiter oben die Option -H).

-r Rechnername
Gibt den SSHFP-Fingerabdruck-Ressourcendatensatz namens Rechnername für die
angegebene Datei des öffentlichen Schlüssels aus.

-s CA-Schlüssel
Zertifiziert (signiert) einen öffentlichen Schlüssel mit dem angegebenen CA-
Schlüssel. Lesen Sie den Abschnitt ZERTIFIKATE für Details.

Beim Erstellen einer KRL gibt -s einen Pfad zu einer CA-Datei eines öffentlichen
Schlüssel an, der zum direkten Sperren von Zertifikaten über die Schlüsselkennung
oder Seriennummer verwandt wird. Siehe den Abschnitt SCHLÜSSELSPERRLISTEN für
Details.

Dieser Schalter kann auch dazu verwandt werden, um den gewünschten Signaturtyp beim
Signieren von Zertifikaten mittels eines RSA-CA-Schlüssels anzugeben. Die
verfügbaren RSA-Signaturvarianten sind »ssh-rsa« (SHA1-Signaturen, nicht empfohlen),
»rsa-sha2-256« und »rsa-sha2-512« (die Vorgabe).

-U Wird diese Option in Kombination mit -s oder -Y sign verwandt, zeigt sie an, dass
sich ein CA-Schlüssel in einem ssh-agent(1) befindet. Siehe den Abschnitt
ZERTIFIKATE für weitere Informationen.

-u Aktualisiert eine KRL. Wird dies zusammen mit -k angegeben, dann werden auf der
Befehlszeile aufgeführte Schlüssel zu der bestehenden KRL hinzugefügt, statt dass
eine neue KRL erstellt wird.

-V Gültigkeitsinterval
Gibt ein Gültigkeitsintervall beim Signieren eines Zertifikats an. Ein
Gültigkeitsintervall kann aus einer einzelnen Zeit bestehen, die angibt, dass das
Zertifikat ab jetzt gültig ist und zu dieser Zeit abläuft. Es kann auch aus zwei
durch Doppelpunkte getrennten Zeiten bestehen, die ein explizites Zeitintervall
anzeigen.

Die Startzeit kann auch wie folgt angegeben werden:
• Der Zeichenkette »always«, um anzuzeigen, dass die Zertifikate keine festgelegte
Startzeit haben.
• Ein Datum oder eine Zeit in der Zeitzone des Systems, formatiert als YYYYMMDD
oder YYYYMMDDHHMM[SS].
• Ein Datum oder eine Zeit in der UTC-Zeitzone als YYYYMMDDZ oder
YYYYMMDDHHMM[SS]Z.
• Eine relative Zeit vor der aktuellen Systemzeit, bestehend aus einem
Minuszeichen, gefolgt von einem Intervall in dem in Abschnitt ZEITFORMATE in
sshd_config(5) beschriebenen Format.
• Rohe Sekunden seit der Epoche (Jan 1 1970 00:00:00 UTC) als hexadezimale Zahl,
beginnend bei »0x«.

Die Endzeit kann ähnlich wie die Startzeit angegeben werden:
• Die Zeichenektte »forever«, um anzuzeigen, dass das Zertifikat keine festgelegte
Endzeit hat.
• Ein Datum oder eine Zeit in der Zeitzone des Systems, formatiert als YYYYMMDD
oder YYYYMMDDHHMM[SS].
• Ein Datum oder eine Zeit in der UTC-Zeitzone als YYYYMMDDZ oder
YYYYMMDDHHMM[SS]Z.
• Eine relative Zeit nach der aktuellen Systemzeit, bestehend aus einem
Pluszeichen, gefolgt von einem Intervall in dem in Abschnitt ZEITFORMATE in
sshd_config(5) beschriebenen Format.
• Rohe Sekunden seit der Epoche (Jan 1 1970 00:00:00 UTC) als hexadezimale Zahl,
beginnend bei »0x«.

Beispiel:

+52w1d Gültig von jetzt bis 52 Wochen und ein Tag von jetzt.

-4w:+4w
Gültig von vor vier Wochen bis zu vier Wochen von jetzt.

20100101123000:20110101123000
Gültig vom 1. Januar 2010, 12:30 Uhr bis 1. Januar 2011, 12:30 Uhr.

20100101123000Z:20110101123000Z
Ähnlich, aber in der UTC-Zeitzone statt der Systemzeitzone interpretiert.

-1d:20110101
Gültig von gestern Mitternacht, 1. Januar 2011.

0x1:0x2000000000
Gültig von grob Anfang 1970 bis Mai 2033.

-1m:forever
Gültig von vor einer Minute und niemals ablaufend.

-v Ausführlicher Modus. Führt dazu, dass ssh-keygen Fehlersuchmeldungen über seinen
Fortschritt ausgibt. Dies ist für die Fehlersuche bei der Moduli-Erstellung
hilfreich. Mehrere -v -Optionen erhöhen die Ausführlichkeit. Das Maximum ist 3.

-w Anbieter
Gibt den Pfad zu einer Bibliothek an, die bei der Erstellung von Schlüsseln, die auf
FIDO-Authentifikatoren liegen, verwandt werden; dies setzt die Vorgabe des Einsatzes
von interner USB-HID-Unterstützung außer Kraft.

-Y find-principals
Findet den/die dem öffentlichen Schlüssel einer Signatur, die mit dem Schalter -s
bereitgestellt wurde, zugeordneten Prinzipale in einer authorisierten Signierer-
Datei, die mit -f angegeben wurde. Das Format der erlaubten Signierer-Datei ist in
dem nachfolgenden Abschnitt ERLAUBTE SIGNIERER beschrieben. Falls eine oder mehrere
der passenden Prinzipale gefunden werden, werden diese auf der Standardausgabe
ausgegeben.

-Y match-principals
Findet Prinzipale in der mit dem Schalter -f festgelegten Signierer-Datei, die auf
den Prinzipalennamen passen, der mit dem Schalter -I bereitgestellt wurde. Falls
eine oder mehrere der passenden Prinzipale gefunden werden, werden diese auf der
Standardausgabe ausgegeben.

-Y check-novalidate
Überprüft, dass die mit ssh-keygen -Y sign erstellte Signatur eine gültige Struktur
hat. Dies validiert nicht, falls die Signatur von einem autorisierten Signierer
kommt. Beim Überprüfen einer Signatur akzeptiert ssh-keygen eine Nachricht auf der
Standardeingabe und einen Signaturnamensraum mittels -n. Es muss auch eine Datei mit
der entsprechenden Signatur mittels des Schalters -s bereitgestellt werden.
Erfolgreiche Überprüfung der Signatur wird von ssh-keygen durch Rückgabe eines Exit-
Status von Null signalisiert.

-Y sign
Signiert eine Datei oder bestimmte Daten mittels eines SSH-Schlüssels
kryptographisch. Beim Signieren akzeptiert ssh-keygen auf der Befehlszeile null oder
mehr Dateien - falls keine Dateien angegeben sind, dann wird ssh-keygen die auf der
Standardeingabe vorhandenen Daten signieren. Signaturen werden auf den Pfad der
Eingabedatei (mit angehängtem ».sig«) oder in die Standardausgabe, falls die zu
signierende Nachricht von der Standardeingabe gelesen wurde, geschrieben.

Der zum Signieren verwandte Schlüssel wird mittels der Option -f angegeben und kann
sich entweder auf einen privaten Schlüssel oder einen öffentlichen Schlüssel, dessen
privater Anteil über ssh-agent(1) verfügbar ist, beziehen. Ein zusätzlicher
Signaturnamensraum, der zur Vermeidung von Signaturchaos über verschiedene
Anwendungsfelder hinweg eingesetzt wird (z.B. Dateisignierung im Vergleich zu E-
Mail-Signierung), muss mit dem Schalter -n angegeben werden. Namensräume sind
beliebige Zeichenketten und können Folgendes beinhalten: »file« für die Signatur von
Dateien, »email« für die Signatur von E-Mails. Für angepasste Einsatzzwecke wird
empfohlen, die Namen gemäß des Musters NAMENSRAUM@IHRE.DOMAIN zu verwenden, um
eindeutige Namensräume zu erstellen.

-Y verify
Erbittet die Überprüfung einer mit ssh-keygen -Y sign wie oben beschrieben
erstellten Signatur. Beim Überprüfen der Signatur akzeptiert ssh-keygen eine
Nachricht auf der Standardeingabe und einen Signaturnamensraum mittels -n. Es muss
auch eine Datei, die die entsprechende Signatur enthält, mit dem Schalter -s
bereitgestellt werden, zusammen mit der Identität des Signierers mittels -I und
einer Liste der erlaubten Signierer mit dem Schalter -f. Das Format der Datei der
erlaubten Signierer ist in dem nachfolgenden Abschnitt ERLAUBTE SIGNIERER
beschrieben. Eine Datei mit gesperrten Schlüsseln kann mit dem Schalter -r übergeben
werden. Die Sperrdatei kann eine KRL oder eine Liste von öffentlichen Schlüsseln,
eine pro Datei, sein. Erfolgreiche Überprüfung durch einen autorisierten Signierer
wird von ssh-keygen durch eine Rückgabe eines Exit-Status von Null signalisiert.

-y Diese Option liest eine Datei eines privaten Schlüssels im OpenSSH-Format ein und
gibt einen öffentlichen OpenSSH-Schlüssel auf die Standardausgabe aus.

-Z Chiffre
Gibt die Chiffre an, die zur Verschlüsselung beim Schreiben von privaten
Schlüsseldateien im OpenSSH-Format verwandt werden soll. Die Liste der verfügbaren
Chiffren kann mittels »ssh -Q cipher« erhalten werden. Die Vorgabe ist »aes256-ctr«.

-z Seriennummer
Gibt eine Seriennummer an, die in das Zertifikat eingebettet werden soll, um dieses
Zertifikat von anderen von der gleichen CA zu unterscheiden. Falls der Seriennummer
das Zeichen »+« vorangestellt wird, dann wird die Seriennummer bei jedem auf einer
einzelnen Befehlszeile signierten Zertifikat erhöht. Die Vorgabeseriennummer ist
Null.

Beim Erstellen einer KRL wird der Schalter -z zur Angabe einer KRL-Versionsnummer
verwandt.

MODULI-ERSTELLUNG

ssh-keygen kann zur Erstellung einer Gruppe für das Diffie-Hellman-Gruppen-Austausch-
Protokoll (DH-GEX) verwandt werden. Das Erstellen ist ein zweistufiger Prozess: zuerst
werden mögliche Primzahlen mittels eines schnellen, aber speicherintensiven Prozesses
erstellt. Diese Kandidatenprimzahlen werden dann auf Eignung geprüft (ein CPU-intensiver
Prozess).

Die Erstellung von Primzahlen wird mit der Option -M generate durchgeführt. Die gewünschte
Länge der Primzahlen kann mit der Option -O bits angegeben werden. Beispiel:

# ssh-keygen -M generate -O bits=2048 moduli-2048.candidates

Standardmäßig beginnt die Suche nach Primzahlen an einem Zufallspunkt in dem gewünschten
Längenbereich. Dies kann mit der Option -O start außer Kraft gesetzt werden, die (in
hexadezimaler Notation) einen anderen Startpunkt angibt.

Sobald eine Kandidatengruppe erstellt wurde, muss sie auf Eignung überprüft werden. Dies
kann mit der Option -M screen erfolgen. In diesem Modus wird ssh-keygen Kandidaten von der
Standardeingabe (oder einer mit der Option -f angegebenen Datei) einlesen. Beispiel:

# ssh-keygen -M screen -f moduli-2048.candidates moduli-2048

Standardmäßig unterliegt jeder Kandidat 100 Primzahlentests. Dies kann mit der Option -O
prime-tests außer Kraft gesetzt werden. Der DH-Erstellerwert wird für die in Untersuchung
befindliche Primzahl automatisch ausgewählt. Falls ein bestimmter Ersteller gewünscht ist,
kann er mit der Option -O generator erbeten werden. Gültige Erstellerwerte sind 2, 3 und 5.

Geprüfte DH-Gruppen können in /etc/ssh/moduli installiert werden. Es ist wichtig, dass diese
Datei Moduli eines Bereichs von Bitlängen enthält.

Für die Moduli-Erstellung und -Überprüfung sind eine Reihe von Optionen mittels des
Schalters -O verfügbar:

lines=Anzahl
Beendet sich nach der Überprüfung der angegebenen Anzahl von Zeilen bei der
Durchführung der DH-Kandidatenprüfung.

start-line=Zeilennummer
Beginnt die Überprüfung bei der angegebenen Zeilennummer bei der Durchführung der
DH-Kandidatenprüfung.

checkpoint=Dateiname
Schreibt die letzte verarbeitete Zeile in die angegebene Datei bei der Durchführung
der DH-Kandidatenprüfung. Dies wird dazu verwandt, Zeilen in der Eingabedatei zu
überspringen, die bereits verarbeitet wurden, wenn der Auftrag erneut gestartet
wird.

memory=Megabyte
Gibt die für die Erstellung von Moduli für DH-GEX zu verwendende Speichermenge (in
Megabyte) an.

start=Hexadezimalwert
Gibt (in hexadezimaler Notation) den Startpunkt bei der Erstellung für Kandiaten-
Moduli für DH-GEX an.

generator=Wert
Gibt den gewünschten Ersteller (in dezimaler Darstellung) bei dem Testen von
Kandidaten-Moduli für DH-GEX an.

ZERTIFIKATE

ssh-keygen unterstützt das Signieren von Schlüsseln, um Zertifikate zu erstellen, die für
Benutzer- oder Rechnerauthentifizierung verwandt werden können. Zertifikate bestehen aus
einem öffentlichen Schlüssel, einigen Identitätsinformationen, einem oder mehreren
Prinzipal- (Benutzer- oder Rechner-)Namen und einer Reihe von Optionen, die mittels des
Schlüssels einer Zertifizierungsstelle (CA) unterschrieben sind. Clients oder Server
brauchen dann nur dem CA-Schlüssel zu vertrauen und ihre Signatur auf einem Zertifikat zu
prüfen, statt vielen Benutzer-/Rechnerschlüsseln zu vertrauen. Beachten Sie, dass OpenSSH-
Schlüssel in einem anderen und viel einfacheren Format als die in ssl(8) verwandten
X.509-Zertifikate sind.

ssh-keygen unterstützt zwei Arten von Zertifikaten: Benutzer und Rechner.
Benutzerzertifikate authentifizieren Benutzer gegenüber Servern, während Rechnerzertifikate
Serverrechner gegenüber Benutzern authentifizieren. Um ein Benutzerzertifikat zu erstellen,
geben Sie Folgendes ein:

$ ssh-keygen -s /Pfad/zum/CA-Schlüssel -I key_id /Pfad/zum/Benutzerschlüssel.pub

Das entstandene Zertifikat wird unter /Pfad/zum/Benutzerschlüssel-Zert.pub abgelegt. Ein
Rechnerzertifikat benötigt die Option -h:

$ ssh-keygen -s /Pfad/zum/CA-Schlüssel -I key_id -h /Pfad/zum/Rechnerschlüssel.pub

Das Rechnerzertifikat wird in /Pfad/zum/Rechnerschlüssel-cert.pub ausgegeben.

Es ist möglich, mittels eines in einem PKCS#11-Token gespeicherten CA-Schlüssel zu
unterschreiben, indem die Token-Bibliothek mittels -D und die öffentliche Hälfte des
kennzeichnenden CA-Schlüssels mit dem Argument von -s bereitgestellt wird:

$ ssh-keygen -s CA-Schlüssel.pub -D libpkcs11.so -I Schlüsselkennung
Benutzerschlüssel.pub

Entsprechend ist es möglich, dass der CA-Schlüssel in einem ssh-agent(1) bereitgestellt
wird. Dies wird durch den Schalter -U angezeigt und auch hier muss der CA-Schlüssel durch
seinen öffentlichen Anteil identifiziert werden.

$ ssh-keygen -Us CA-Schlüssel.pub -I Schlüsselkennung Benutzerschlüssel.pub

In allen Fällen ist die Schlüsselkennung ein »Schlüsselkennzeichner«, der durch den Server
protokolliert wird, wenn das Zertifikat zur Authentifizierung verwandt wird.

Zertifikate können in ihrer Gültigkeit auf eine Reihe Prinzipalennamen (Benutzer/Rechner)
beschränkt werden. Standardmäßig sind erstellte Zertifikate für alle Benutzer oder Rechner
gültig. Um ein Zertifikat für eine bestimmte Gruppe von Prinzipalen zu erstellen, verwenden
Sie Folgendes:

$ ssh-keygen -s CA-Schlüssel -I Schlüsselkennung -n Benutzer1,Benutzer2
Benutzerschlüssel.pub
$ ssh-keygen -s CA-Schlüssel -I Schlüsselkennung -h -n Rechner.Domain
Rechnerschlüssel.pub

Zusätzliche Beschränkungen für die Gültigkeit und den Einsatz von Benutzerzertifikaten
können durch Zertifikatsoptionen angegeben werden. Eine Zertifikatsoption kann
Funktionalitäten von der SSH-Sitzung deaktivieren, kann nur bei dem Einsatz von bestimmten
Quelladressen gültig sein oder kann die Ausführung eines bestimmten Befehls erzwingen.

Die für Benutzerzertifikate gültigen Optionen sind:

clear Setzt alle aktivierten Berechtigungen zurück. Dies ist nützlich, um die Vorgabemenge
an Berechtigungen zurückzusetzen, so dass Berechtigungen individuell hinzugefügt
werden können.

critical:Name[=Inhalte]
extension:Name[=Inhalte]
Enthält eine beliebige kritische Zertifikatsoption oder -Erweiterung. Der angegebene
Name sollte eine Domain-Endung enthalten, z.B. »name@example.com«. Falls Inhalte
angegeben sind, dann werden sie als Inhalte der Erweiterung/Option (kodiert als
Zeichenkette) aufgenommen, andernfalls wird die Erweiterung/Option ohne Inhalte
erstellt, was normalerweise einen Schalter anzeigt. Erweiterungen können von einem
Client oder Server, der diese nicht erkennt, ignoriert werden, während kritische
Optionen dazu führen werden, dass das Zertifikat abgelehnt wird.

force-command=Befehl
Erzwingt die Ausführung von Befehl statt einer von einem Benutzer angegebene Shell
oder eines Befehls, wenn das Zertifikat zur Authentifizierung verwandt wird.

no-agent-forwarding
Deaktiviert ssh-agent(1) -Weiterleitung (standardmäßig erlaubt).

no-port-forwarding
Deaktiviert Port-Weiterleitung (standardmäßig erlaubt).

no-pty Deaktiviert PTY-Zuweisung (standardmäßig erlaubt).

no-user-rc
Deaktiviert Ausführung von ~/.ssh/rc durch sshd(8) (standardmäßig erlaubt).

no-x11-forwarding
Deaktiviert X11-Weiterleitung (standardmäßig erlaubt).

permit-agent-forwarding
Erlaubt die ssh-agent(1) -Weiterleitung.

permit-port-forwarding
Erlaubt die Port-Weiterleitung.

permit-pty
Erlaubt PTY-Zuweisung.

permit-user-rc
Erlaubt die Ausführung von ~/.ssh/rc durch sshd(8).

permit-X11-forwarding
Erlaubt die X11-Weiterleitung.

no-touch-required
Es wird nicht verlangt, dass mit diesem Schlüssel erfolgte Signaturen den Nachweis
der Anwesenheit des Benutzers enthalten (z.B. indem der Benutzer den Authentifikator
berührt). Diese Option ergibt nur für FIDO-Authentifikatoralgorithmen ecdsa-sk und
ed25519-sk Sinn.

source-address=Adressenliste
Beschränkt die Quelladressen, aus der Zertifikate als gültig betrachtet werden. Die
Adressenliste ist eine Kommata-getrennte Liste von einen oder mehreren
Adresse/Netzmaske-Paaren im CIDR-Format.

verify-required
Es wird verlangt, dass mit diesem Schlüssel erfolgte Signaturen anzeigen, dass der
Benutzer zuerst überprüft wurde. Diese Option ergibt nur für FIDO-
Authentifikatoralgorithmen ecdsa-sk und ed25519-sk Sinn. Derzeit ist PIN-
Authentifizierung die einzige unterstützte Überprüfungsmethode, aber andere Methoden
könnten in der Zukunft unterstützt werden.

Derzeit sind für Rechnerschlüssel keine Standardoptionen gültig.

Schließlich können Zertifikate mit einer Gültigkeitslebensdauer definiert werden. Die Option
-V erlaubt die Angabe von Start- und Endzeiten des Zertifikats. Ein Zertifikat, das
außerhalb dieses Bereichs vorgewiesen wird, wird nicht als gültig betrachtet. Standardmäßig
sind Zertifikate von der UNIX -Epoche bis zur fernen Zukunft gültig.

Damit Zertifikate zur Benutzer- oder Rechnerauthentifizierung verwandt werden können, muss
dem öffentlichen Schlüssel der CA durch sshd(8) oder ssh(1) vertraut werden. Lesen Sie deren
Handbuchseiten für Details.

FIDO-AUTHENTIFIKATOR

ssh-keygen kann FIDO-Authentifikator-basierende Schlüssel erstellen. Anschließend können
diese fast genauso wie jeder andere, von OpenSSH unterstützte Schlüsseltyp verwandt werden,
so lange wie der Hardware-Authentifikator angestöpselt ist, während die Schlüssel verwandt
werden. FIDO-Authentifikatoren verlangen im Allgemeinen vom Benutzer eine explizite
Authentifizierungsaktion, indem sie berührt oder angetippt werden. FIDO-Schlüssel bestehen
aus zwei Anteilen: Einem Schlüsselverwalteranteil, der in der privaten Schlüsseldatei auf
Platte gespeichert ist, und einen geräteabhängigen privaten Schlüssel, der für jeden FIDO-
Authentifikator eindeutig ist und der nicht von der Authentifikator-Hardware exportiert
werden kann. Diese werden durch die Hardware zum Zeitpunkt der Authentifizierung kombiniert,
um den echten Schlüssel abzuleiten, der zur Signatur von Authentifizierungs-
Herausforderungen verwandt wird. Unterstützte Schlüsseltypen sind ecdsa-sk und ed25519-sk.

Die für FIDO-Schlüssel gültigen Optionen sind:

application
Setzt die Standard-FIDO-Anwendungs-/Ursprungszeichenkette (»ssh:«) außer Kraft. Das
kann nützlich sein, wenn Rechner- oder Domain-spezifische residente Schlüssel
erstellt werden. Die angegebene Anwendungszeichenkette muss mit »ssh:« anfangen.

challenge=Pfad
Gibt einen Pfad zu einer Herausforderungszeichenkette an, die an den FIDO-
Authentifikator während der Schlüsselerstellung übergeben wird. Die
Herausforderungszeichenkette kann als Teil eines Außerbandprotokolls zur
Schlüsselregistrierung verwandt werden (standardmäßig wird eine zufällige
Herausforderung verwandt).

device Gibt das zu verwendende fido(4) -Gerät explizit an, statt die Authentifikator-
Middleware eines auswählen zu lassen.

no-touch-required
Zeigt an, dass der erstellte private Schlüssel keine Berührungsereignisse
(Anwesenheit des Benutzers) bei der Erstellung von Signaturen erfordern soll.
Beachten Sie, dass sshd(8) standardmäßig solche Signaturen ablehnen wird, außer dies
wird mit einer authorized_keys-Option außer Kraft gesetzt.

resident
Zeigt an, dass der Schlüssel-Handhaber auf dem FIDO-Authentifikator selbst
gespeichert werden soll. Dies erleichtert die Verwendung des Authentifikators auf
mehreren Computern. Residente Schlüssel könnten auf FIDO2-Authentifikatoren
unterstützt werden und benötigen typischerweise, dass auf dem Authentifikator vor
der Erstellung eine PIN gesetzt wird. Residente Schlüssel können von dem
Authentifikator mittels ssh-add(1) heruntergeladen werden. Durch Speichern beider
Teile eines Schlüssels auf einem FIDO-Authentifikator wird die Wahrscheinlichkeit
erhöht, dass ein Angreifer in der Lage ist, ein gestohlenes Authentifikator-Gerät zu
verwenden.

user Ein Benutzername, der einem residenten Schlüssel zugeordnet werden soll und den
standardmäßigen Benutzernamen außer Kraft setzt. Die Angabe eines Benutzernamens
könnte bei der Erstellung mehrfacher residenter Schlüssel für den gleichen
Anwendungsnamen nützlich sein.

verify-required
Zeigt an, dass dieser private Schlüssel für jede Signatur eine Benutzerüberprüfung
benötigen soll. Nicht alle FIDO-Authentifikatoren unterstützen diese Option. Derzeit
ist PIN-Authentifizierung die einzige unterstützte Methode, aber in der Zukunft
können weitere Methoden unterstützt werden.

write-attestation=Pfad
Kann zum Zeitpunkt der Schlüsselerstellung verwandt werden, um die von FIDO-
Authentifikatoren während der Schlüsselerstellung zurückgelieferten
Beglaubigungsdaten aufzuzeichnen. Diese Informationen sind möglicherweise sensitiv.
Standardmäßig wird diese Information verworfen.

SCHLÜSSELSPERRLISTEN

ssh-keygen kann SCHLÜSSELSPERRLISTEN (KRLs) im OpenSSH-Format verwalten. Diese Binärdateien
geben Schlüssel oder Zertifikate, die gesperrt werden sollen, in einem kompakten Format an,
wobei nur ein Bit pro Zertifikat benötigt wird, falls das Sperren über die Seriennummer
erfolgt.

KRLs können mit dem Schalter -k erstellt werden. Diese Option liest eine oder mehrere
Dateien von der Befehlszeile ein und erstellt eine neue KRL. Die Dateien können entweder
eine KRL-Spezifikation (siehe unten) oder öffentliche Schlüssel, einen pro Zeile, enthalten.
Einfache öffentliche Schlüssel werden gesperrt, indem ihr Hash oder Inhalt in der KRL
aufgeführt werden und Zertifikate werden über die Seriennummer oder die Schlüsselkennung
(falls die Seriennummer Null oder nicht verfügbar ist) gesperrt.

Das Sperren von Schlüsseln mit einer KRL-Spezifikation ermöglicht die genaue Steuerung über
die Arten von Datensätzen, die zum Sperren von Schlüsseln verwandt werden, und kann
verwendet werden, um Zertifikate direkt über die Seriennummer oder Schlüsselkennung zu
sperren, ohne dass das vollständige Zertifikat vorliegen muss. Eine KRL-Spezifikation
besteht aus Zeilen, die eine oder mehrere der nachfolgenden Direktiven, gefolgt von einem
Doppelpunkt und einigen Direktiven-spezifischen Informationen, enthalten.

serial: Seriennummer[-Seriennummer]
Sperrt ein Zertifikat mit der angegebenen Seriennummer. Seriennummern sind 64-Bit-
Werte, ohne Nullen und können dezimal, hexadezimal oder oktal angegeben werden.
Falls zwei durch Bindestriche getrennte Seriennummern angegeben sind, dann wird der
Seriennummernbereich, einschließlich und zwischen ihnen gesperrt. Der CA-Schlüssel
muss auf der Befehlszeile von ssh-keygen mit der Option -s angegeben worden sein.

id: Schlüsselkennung
Sperrt ein Zertifikat mit der angegebenen Schlüsselkennungszeichenkette. Der CA-
Schlüssel muss auf der Befehlszeile von ssh-keygen mit der Option -s angegeben
worden sein.

key: öffentlicher_Schlüssel
Sperrt den angegebenen Schlüssel. Falls ein Zertifikat aufgeführt ist, dann wird es
als einfacher öffentlicher Schlüssel gesperrt.

sha1: öffentlicher_Schlüssel
Sperrt den angegebenen Schlüssel durch Aufnahme seines SHA1-Hashes in die KRL.

sha256: öffentlicher_Schlüssel
Sperrt den angegebenen Schlüssel durch Aufnahme seines SHA256-Hashes in die KRL.
KRLs, die Schlüssel durch SHA256-Hashes sperren, werden von OpenSSH-Versionen vor
7.9 nicht unterstützt.

hash: Fingerabdruck
Sperrt einen Schlüssel mittels eines Fingerabdruck-Hashes, wie er von einer sshd(8)
-Authentifizierungs-Protokollnachricht oder dem Schalter -l von ssh-keygen erlangt
werden kann. Hier werden nur SHA256-Fingerabdrücke unterstützt und resultierende
KRLs werden von OpenSSH-Versionen vor 7.9 nicht unterstützt.

KRLs können zusätzlich zu -k auch mit dem Schalter -u aktualisiert werden. Wird diese Option
angegeben, werden die auf der Befehlszeile aufgeführten Schlüssel mit der KRL
zusammengeführt, wobei die dort befindlichen hinzugefügt werden.

Liegt eine KRL vor, ist es auch möglich, zu prüfen, ob es einen oder mehrere bestimmte(n)
Schlüssel sperrt. Der Schalter -Q wird eine bestehende KRL befragen und jeden auf der
Befehlszeile übergebenen Schlüssel testen. Falls ein auf der Befehlszeile aufgeführter
Schlüssel gesperrt wurde (oder ein Fehler auftrat), dann wird ssh-keygen sich mit einem von
Null verschiedenen Exit-Status beenden. Der Exit-Status 0 wird nur zurückgeliefert, falls
kein Schlüssel gesperrt wurde.

ERLAUBTE SIGNIERER

     Bei der Überprüfung von Signaturen verwendet ssh-keygen eine einfache Liste von Identitäten
     und Schlüsseln, um zu bestimmen, ob eine Signatur von einer autorisierten Quelle kommt.
     Diese »erlaubte Signierer«-Datei verwendet ein Format, das dem Muster des in
     »AUTHORIZED_KEYS-DATEIFORMAT« in sshd(8) beschriebenen Formats folgt. Jede Zeile der Datei
     enthält die folgenden, durch Leerraum getrennten Felder: Prinzipale, Optionen, Schlüsseltyp,
     Schlüssel (Base64-kodiert), leere Zeilen und solche, die mit einem ‘#’ beginnen, werden als
     Kommentare ignoriert.

     Das Prinzipale-Feld ist eine Musterliste (siehe MUSTER in ssh_config(5)), die aus einem oder
     mehreren, durch Kommata getrennten BENUTZER@DOMAIN-Identitätsmustern, die zum Signieren
     akzeptiert werden, besteht. Beim Überprüfen muss die mittels der Option -I präsentierten
     Identitäten auf das Prinzipalenmuster passen, damit der entsprechende Schlüssel als für die
     Überprüfung akzeptierbar betrachtet wird.

     Falls Optionen vorhanden sind, werden diese durch Kommata getrennt angegeben. Leerzeichen
     sind nur innerhalb doppelter englischer Anführungszeichen erlaubt. Die folgenden
     Optionsangaben werden unterstützt (beachten Sie, dass bei Optionsschlüsselwörtern die
     Groß-/Kleinschreibung egal ist):

     cert-authority
             Zeigt an, dass dieser Schlüssel als Zertifizierungsstelle (CA) akzeptiert ist und
             dass Zertifikate, die von dieser CA signiert wurden, zur Überprüfung akzeptiert
             werden.

     namespaces=Namensraumliste
             Gibt eine Musterliste von Namensräumen an, die für diesen Schlüssel akzeptiert
             werden. Falls diese Option vorhanden ist, muss der in dem Signaturobjekt
             eingebettete und auf der Befehlszeile zur Überprüfung angegegebene
             Signaturnamensraum auf die angegebene Liste passen, bevor der Schlüssel als
             akzeptierbar betrachtet wird.

     valid-after=Zeitstempel
             Zeigt an, dass der Schlüssel für die Verwendung zum oder nach dem angegebenen
             Zeitstempel (ein Datum oder eine Zeit im Format YYYYMMDD[Z] oder
             YYYYMMDDHHMM[SS][Z]) gültig ist. Daten und Uhrzeiten werden in der aktuellen
             Systemzeitzone interpretiert, außer ein Zeichen »Z« wird angehängt, dann werden sie
             in der UTC-Zeitzone interpretiert.

     valid-before=Zeitstempel
             Zeigt an, dass der Schlüssel zur Verwendung am oder bevor dem festgelegten
             Zeitstempel gültig ist.

     Bei der Überprüfung von durch Zertifikaten erstellten Signaturen muss der Prinzipalenname
     sowohl auf das Prinzipalenmuster in der Datei der erlaubten Signierer als auch auf die im
     Zertifikat eingebetteten Prinzipale passen.

     Ein Beispiel für eine Datei erlaubter Signierer:

        # Kommentare am Anfang der Zeile erlaubt
        Benutzer1@example.com,Benutzer2@example.com ssh-rsa AAAAX1…
        # Eine Zertifikatsautorität, der für alle Prinzipale in einer Domain vertraut wird.
        *@example.com cert-authority ssh-ed25519 AAAB4…
        # Ein Schlüssel, der nur für Dateisignaturen akzeptiert wird.
        Benutzer2@example.com namespaces="file" ssh-ed25519 AAA41…

UMGEBUNGSVARIABLEN

     SSH_SK_PROVIDER
             Gibt einen Pfad zu einer Bibliothek an, die beim Laden jedes FIDO-Authentifikator-
             basierten Schlüssels verwandt wird. Dies setzt die standardmäßige, eingebaute USB-
             HID-Unterstützung außer Kraft.

DATEIEN

~/.ssh/id_dsa
~/.ssh/id_ecdsa
~/.ssh/id_ecdsa_sk
~/.ssh/id_ed25519
~/.ssh/id_ed25519_sk
~/.ssh/id_rsa
Enthält die DSA-, ECDSA-, Authentifikator-basierte ECDSA-, Ed25519-,
Authentifikator-basierte Ed25519- oder RSA-Authentifizierungsidentität des
Benutzers. Diese Datei sollte nur durch den Benutzer lesbar sein. Es ist möglich,
bei der Erstellung eines Schlüssels eine Passphrase anzugeben; diese Passphrase wird
zur Verschlüsselung des privaten Anteils der Datei mittels 128-Bit AES verwandt.
ssh-keygen greift nicht automatisch auf diese Datei zu, sie wird aber als die
Vorgabedatei für den privaten Schlüssel angeboten. ssh(1) wird diese Datei lesen,
wenn ein Anmeldeversuch erfolgt.

~/.ssh/id_dsa.pub
~/.ssh/id_ecdsa.pub
~/.ssh/id_ecdsa_sk.pub
~/.ssh/id_ed25519.pub
~/.ssh/id_ed25519_sk.pub
~/.ssh/id_rsa.pub
Enthält den öffentlichen DSA-, ECDSA-, Authentifikator-basierten ECDSA-, Ed25519-,
Authentifikator-basierten Ed25519- oder RSA-Schlüssel zur Authentifizierung. Der
Inhalt dieser Datei sollte auf allen Maschinen, auf denen sich der Benutzer mittels
Authentifizierung mit öffentlichen Schlüsseln anmelden möchte, zu
~/.ssh/authorized_keys hinzugefügt werden. Es ist nicht notwendig, die Inhalte
dieser Dateien geheimzuhalten.

/etc/ssh/moduli
Enthält Diffie-Hellman-Gruppen zur Verwendung mit DH-GEX. Das Dateiformat ist in
moduli(5) beschrieben.

SIEHE AUCH

     ssh(1), ssh-add(1), ssh-agent(1), moduli(5), sshd(8) »Das Format der öffentlichen Schlüssel
     der Secure Shell (SSH)«, RFC 4716, 2006.

AUTOREN

     OpenSSH ist eine Ableitung der ursprünglichen und freien SSH-1.2.12-Veröffentlichung durch
     Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt und Dug
     Song entfernten viele Fehler, fügten neuere Funktionalitäten wieder hinzu und erstellten
     OpenSSH. Markus Friedl steuerte die Unterstützung für SSH-Protokollversion 1.5 und 2.0 bei.

ÜBERSETZUNG

     Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann
     <debian@helgefjell.de> erstellt.

     Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version
     3: https://www.gnu.org/licenses/gpl-3.0.html oder neuer bezüglich der Copyright-Bedingungen.
     Es wird KEINE HAFTUNG übernommen.

     Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-
     Mail an die Mailingliste der Übersetzer: debian-l10n-german@lists.debian.org .