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

erstellt, verwaltet und wandelt Authentifizierungsschlüssel für ssh(1) um. 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 ohne Argumente aufgerufen
wird, erstellt es einen Ed25519-Schlüssel.

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 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 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.

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 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 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 , 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 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 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 -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 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 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 auf der Befehlszeile null oder mehr Dateien - falls keine Dateien angegeben
sind, dann wird 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 -Y sign wie oben beschrieben erstellten Signatur. Beim
Überprüfen der Signatur akzeptiert 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 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

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 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

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.

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

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

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 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 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 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 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 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. 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 .

Debian                                         4. September, 2023                                  SSH-KEYGEN(1)