ssh-keygen —
Dienstewerkzeug für
OpenSSH-Authentifizierungsschlüssel
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]
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 RSA-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.
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.
-
-t
dsa |
ecdsa
|
ecdsa-sk
|
ed25519
|
ed25519-sk
|
rsa
- Gibt den Typ des zu erstellenden Schlüssels an. Die
möglichen Werte sind »dsa«, »ecdsa«,
»ecdsa-sk«, »ed25519«,
»ed25519-sk« und »rsa«.
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 [email protected] 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.
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.
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.
»[email protected]«. 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.
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.
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.
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
[email protected],[email protected] 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.
[email protected] namespaces="file" ssh-ed25519 AAA41…
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.
- ~/.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.
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.
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.
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann
<
[email protected]> erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die
GNU
General Public License Version 3 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:
[email protected]