| SSH-KEYGEN(1) | General Commands Manual | SSH-KEYGEN(1) |
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 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-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-B-b
Bits-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-c-D
pkcs11-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-e-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-H verwandt werden,
um gefundene Schlüssel in einem gehashten Format anzuzeigen.-f
Dateiname-g-r das generische
DNS-Format.-Hssh 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-I
Zertifikatsidentität-i-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-kssh-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-lssh-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-M
screen-m
Schlüsselformat-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-n
Prinzipale-O
Optionssh-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=Algorithmusprint-pubkeyverify-time=ZeitstempelBei der Erstellung von SSHFP-DNS-Datensätzen aus
öffentlichen Schlüsseln mittels des Schalters
-r werden die folgenden Optionen akzeptiert:
hashalg=Algorithmus-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-p-Q-l angegeben wurde, dann werden die
Inhalte der KRL ausgegeben.-qssh-keygen zum Schweigen.-R
Rechnername |
[Rechnername]:Port-H).-r
Rechnername-s
CA-SchlüsselBeim 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
|
rsaDieser 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-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-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ültigkeitsintervalDie Startzeit kann auch wie folgt angegeben werden:
Die Endzeit kann ähnlich wie die Startzeit angegeben werden:
Beispiel:
-vssh-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-Y
find-principals-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-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-novalidatessh-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
signssh-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
verifyssh-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-Z
Chiffre-z
SeriennummerBeim 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.candidatesStandardmäß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-2048Standardmäß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=Anzahlstart-line=Zeilennummercheckpoint=Dateinamememory=Megabytestart=Hexadezimalwertgenerator=Wertssh-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.pubDas 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.pubDas 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.pubEntsprechend 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.pubIn 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.pubZusä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:
clearcritical:Name[=Inhalte]extension:Name[=Inhalte]force-command=Befehlno-agent-forwardingno-port-forwardingno-ptyno-user-rcno-x11-forwardingpermit-agent-forwardingpermit-port-forwardingpermit-ptypermit-user-rcpermit-X11-forwardingno-touch-requiredecdsa-sk und ed25519-sk
Sinn.
source-address=Adressenlisteverify-requiredecdsa-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:
applicationchallenge=Pfaddeviceno-touch-requiredresidentuserverify-requiredwrite-attestation=Pfadssh-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]ssh-keygen mit der
Option -s angegeben worden sein.id:
Schlüsselkennungssh-keygen mit der Option
-s angegeben worden sein.key:
öffentlicher_Schlüsselsha1:
öffentlicher_Schlüsselsha256:
öffentlicher_Schlüsselhash:
Fingerabdruck-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):
namespaces=Namensraumlistevalid-after=Zeitstempelvalid-before=ZeitstempelBei 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…
SSH_SK_PROVIDERssh-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(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 <debian@helgefjell.de> 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: debian-l10n-german@lists.debian.org
| $Mdocdate: 4. September 2023 $ | Debian |