SSH-KEYGEN(1) General Commands Manual SSH-KEYGEN(1) NOM ssh-keygen - Utilitaire d'OpenSSH pour la gestion des cles d'authentification SYNOPSIS ssh-keygen [-q] [-a passes] [-b bits] [-C commentaire] [-f fichier_cle_sortie] [-m format] [-N nouvelle_phrase_secrete] [-O option] [-t ecdsa | ecdsa-sk | ed25519 | ed25519-sk | rsa] [-w fournisseur] [-Z algo_chiffrement] ssh-keygen -p [-a passes] [-f fichier_cle] [-m format] [-N nouvelle_phrase_secrete] [-P ancienne_phrase_secrete] [-Z algo_chiffrement] ssh-keygen -i [-f fichier_cle_entree] [-m format_cle] ssh-keygen -e [-f fichier_cle_entree] [-m format_cle] ssh-keygen -y [-f fichier_cle_entree] ssh-keygen -c [-a passes] [-C commentaire] [-f fichier_cle] [-P phrase_secrete] ssh-keygen -l [-v] [-E hachage_empreinte] [-f fichier_cle_entree] ssh-keygen -B [-f fichier_cle_entree] ssh-keygen -D pkcs11 ssh-keygen -F nom_hote [-lv] [-f fichier_hotes_connus] ssh-keygen -H [-f fichier_hotes_connus] ssh-keygen -K [-a passes] [-w fournisseur] ssh-keygen -R nom_hote [-f fichier_hotes_connus] ssh-keygen -r nom_hote [-g] [-f fichier_cle_entree] ssh-keygen -M generate [-O option] fichier_sortie ssh-keygen -M screen [-f fichier_entree] [-O option] fichier_sortie ssh-keygen -I identite_certificat -s cle_CA [-hU] [-D fournisseur_pkcs11] [-n principals] [-O option] [-V intervalle_validite] [-z numero_serie] file ... ssh-keygen -L [-f fichier_cle_entree] ssh-keygen -A [-a passes] [-f chemin_prefixe] ssh-keygen -k -f fichier_krl [-u] [-s cle_publique_ca] [-z numero_version] file ... ssh-keygen -Q [-l] -f fichier_krl file ... ssh-keygen -Y find-principals [-O option] -s fichier_signature -f fichier_signataires_autorises ssh-keygen -Y match-principals -I identite_signataire -f fichier_signataires_autorises ssh-keygen -Y check-novalidate [-O option] -n espace_noms -s fichier_signature ssh-keygen -Y sign [-O option] -f fichier_cle -n espace_noms file ... ssh-keygen -Y verify [-O option] -f fichier_signataires_autorises -I identite_signataire -n espace_noms -s fichier_signature [-r fichier_revocation] DESCRIPTION ssh-keygen genere, gere et convertit les cles d'authentification pour ssh(1). ssh-keygen permet de creer des cles a utiliser avec la version 2 du protocole SSH. Le type de cle a generer est specifie a l'aide de l'option -t. Invoquee sans argument, ssh-keygen generera une cle Ed25519. ssh-keygen permet aussi de generer des groupes a utiliser dans le cadre de l'echange de groupe Diffie-Hellman (DH-GEX). Voir la section GENERATION DES MODULI pour les details. Enfin, ssh-keygen permet de generer et mettre a jour les listes de revocation de cle et de tester si certaines cles ont ete revoquees par une de ces listes. Voir la section LISTES DE REVOCATION DE CLES pour les details. En general, chaque utilisateur souhaitant utiliser SSH avec une authentification par cle publique lance ce programme une fois pour generer la cle d'authentification dans ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519, ~/.ssh/id_ed25519_sk ou ~/.ssh/id_rsa. Eventuellement, l'administrateur systeme peut utiliser ce programme pour generer des cles d'hote, comme on le voit dans /etc/rc. Normalement, ce programme genere la cle et demande un nom de fichier pour stocker la cle privee. La cle publique est stockee dans un fichier de meme nom suffixe par << .pub >>. Le programme demande aussi une phrase secrete. La phrase secrete peut etre vide, ce qui equivaut une absence de phrase secrete (les cles d'hote doivent avoir une phrase secrete vide), ou une chaine de caracteres de longueur quelconque. Une phrase secrete est semblable a un mot de passe, a la difference qu'elle peut etre une phrase avec des mots, des caracteres de ponctuation, des chiffres, des blancs ou n'importe quelle chaine de caracteres. Une bonne phrase secrete doit comporter 10 a 30 caracteres et ne doit pas etre une phrase simple ou facile a deviner (pour information, la prose anglaise a seulement un a deux bits d'entropie par caractere et fournit de tres mauvaises phrases secretes) ; elle doit en outre comporter un melange de capitales, de minuscules, de chiffres et de caracteres non alphanumeriques. La phrase secrete peut etre modifiee par la suite a l'aide de l'option -p. Il n'y a aucun moyen de retrouver une phrase secrete oubliee. Si on oublie la phrase secrete, il faut generer une nouvelle cle et copier la cle publique correspondante sur les autres machines. Par defaut, ssh-keygen genere les cles sous un format specifique a OpenSSH. Ce format est prefere, car il offre une meilleure protection des cles a son emplacement et permet le stockage des commentaires de la cle dans le fichier de cle privee lui-meme. Le commentaire de la cle peut faciliter l'identification de la cle. Son contenu initial est << utilisateur@hote >> a la creation de la cle, mais il peut etre modifie a l'aide de l'option -c. ssh-keygen peut encore generer des cles privees au format PEM precedemment utilise en specifiant l'option -m. Cette option peut etre utilisee pour generer une nouvelle cle ou, pour une cle existante au nouveau format, convertir cette derniere en utilisant cette option en combinaison avec l'option -p (changer la phrase secrete). Une fois la cle generee, ssh-keygen demandera ou stocker les cles pour les activer. Les options sont les suivantes : -A Generer des cles d'hote de tous les types de cle par defaut (rsa, ecdsa et ed25519) si elles n'existent par deja. Les cles d'hote sont generees avec le chemin du fichier de cle par defaut, une phrase secrete vide, les bits par defaut pour le type de cle et un commentaire par defaut. Si l'option -f a aussi ete specifiee, son argument est utilise comme prefixe pour le chemin par defaut des fichiers de cle d'hote resultants. Cette option est utilisee par /etc/rc pour generer de nouvelles cles d'hote. -a passes Lors de l'enregistrement d'une cle privee, cette option permet de specifier le nombre de passes KDF (key derivation function, actuellement bcrypt_pbkdf(3)) utilise. Un nombre plus eleve implique une verification plus lente de la phrase secrete et augmente la resistance aux tentatives de craquage du mot de passe par force brute (en cas de vol de cles). La valeur par defaut est de 16 passes. -B Cette option permet d'afficher un condense << bubblebabble >> (encode en alternant consonnes et voyelles, NDT) du fichier de cle privee ou publique specifie. -b bits Cette option permet de specifier le nombre de bits que la cle a creer devra comporter. Pour les cles RSA, la valeur minimale est de 1024 bits et la valeur par defaut est de 3072 bits. En general, on considere qu'une longueur de 3072 bits est suffisante. Pour les cles ECDSA, l'option -b determine la longueur de la cle en specifiant une des trois tailles de courbe elliptique suivantes : 256, 384 ou 521 bits. Toute tentative d'utiliser des tailles autres que ces trois valeurs pour une cle ECDSA echouera. Les cles ECDSA-SK, Ed25519 et Ed25519-SK possedent une taille fixe et dans leur cas, l'option -b sera ignoree. -C comment Cette option permet de fournir un nouveau commentaire. -c Cette option permet de changer le commentaire des fichiers de cles publique et privee. Le programme demande de fournir le nom du fichier contenant la cle privee, la phrase secrete si la cle en possede une et le nouveau commentaire. -D pkcs11 Cette option permet de telecharger les cles publiques fournies par la bibliotheque partagee PKCS#11 pkcs11. Lorsqu'elle est utilisee en combinaison avec l'option -s, cette option indique qu'une cle de CA reside dans un jeton PKCS#11 (voir la section CERTIFICATS pour les details). -E hachage_empreinte Cette option permet de specifier l'algorithme de hachage utilise pour l'affichage des empreintes de cle. Les options valables sont << md5 >> et << sha256 >>. La valeur par defaut est << sha256 >>. -e Cette option lit un fichier de cle publique ou privee D'OpenSSH et affiche la cle publique sur la sortie standard sous un des formats specifies a l'aide de l'option -m. Le format d'export par defaut est << RFC4716 >>. Cette option permet d'exporter des cles d'OpenSSH pour qu'elles puissent etre utilisees par d'autres programmes, a l'instar de plusieurs implementations commerciales de SSH. -F nom_hote | [nom_hote]:port Rechercher le nom_hote specifie (avec un numero de port optionnel) dans un fichier known_hosts en listant toutes les occurrences trouvees. Cette option s'avere utile pour trouver des adresses ou des noms d'hote haches et permet aussi, en combinaison avec l'option -H, d'afficher les cles trouvees sous un format hache. -f nom_fichier Cette option permet de specifier le nom du fichier de cle. -g Utiliser le format DNS generique pour l'affichage d'enregistrements de ressources de type empreinte a l'aide de l'option -r. -H Cette option permet de hacher un fichier known_hosts. Elle remplace tous les noms d'hote et adresses par leur representation hachee dans le fichier specifie ; le contenu originel est deplace vers un fichier de meme nom suffixe par << .old >>. Ces hachages peuvent normalement etre utilises par ssh et sshd, mais ils ne revelent aucune information d'identification en cas de divulgation du contenu du fichier. Cette option ne modifie pas les noms d'hote haches existants et peut donc etre utilisee en toute securite avec des fichiers qui melangent des noms haches et non haches. -h Lors de la signature d'une cle, creer un certificat d'hote au lieu d'un certificat d'utilisateur. Voir la section CERTIFICATS pour les details. -I identite_certificat Cette option permet de specifier l'identite de la cle lors de la signature d'une cle publique. Voir la section CERTIFICATS pour les details. -i Cette option lit un fichier de cle privee (ou publique) non chiffre dans le format specifie a l'aide de l'option -m et affiche une cle privee (ou publique) compatible avec OpenSSH sur la sortie standard. Cette option permet d'importer des cles depuis d'autres logiciels, a l'instar de plusieurs implementations commerciales de SSH. -K Telecharger des cles residentes depuis un authentificateur FIDO. Les fichiers de cle publique et privee correspondant a chaque cle telechargee seront ecrits dans le repertoire actuel. Si plusieurs authentificateurs FIDO sont attaches, les cles seront telechargees depuis le premier authentificateur atteint. Voir la section AUTHENTIFICATEUR FIDO pour plus d'informations. -k Cette option permet de generer un fichier KRL. Dans ce mode, ssh-keygen genere un fichier KRL a l'emplacement specifie a l'aide de l'option -f qui revoque toute cle ou tout certificat present sur la ligne de commande. Les cles ou certificats a revoquer peuvent etre specifies a l'aide du fichier de cle publique correspondant ou en utilisant le format decrit dans la section LISTES DE REVOCATION DE CLES. -L Afficher le contenu d'un ou plusieurs certificats. -l Cette option permet d'afficher l'empreinte du fichier de cle publique specifie. ssh-keygen essaie de trouver le fichier de cle publique correspondant et affiche son empreinte. En combinaison avec l'option -v, cette option affiche une representation visuelle de la cle en art ASCII en plus de l'empreinte. -M generate Cette option permet de generer une proposition de parametres Diffie-Hellman Group Exchange (DH-GEX) pour une utilisation eventuelle par les methodes d'echange de cles << diffie-hellman- group-exchange-* >>. Les nombres generes par cette operation doivent etre examines plus en detail avant utilisation. Voir la section GENERATION DES MODULI pour plus d'informations. -M screen Examiner une proposition de parametres Diffie-Hellman Group Exchange. Cette option accepte en argument une liste de parametres suggeres et verifie s'ils sont des nombres premiers surs (nombres premiers de Sophie Germain) avec des generateurs de groupe acceptables. Les resultats de cette operation peuvent etre ajoutes au fichier /etc/ssh/moduli. Voir la section GENERATION DES MODULI pour plus d'informations. -m format_cle Cette option permet de specifier un format de cle pour la creation de cle, les options de conversion -i (import) et -e (export) et l'operation de changement de phrase secrete -p. Cette derniere permet d'effectuer une conversion entre les formats de cle privee OpenSSH et PEM. Les formats de cle pris en charge sont : << RFC4716 >> (cle publique ou privee RFC 4716/SSH2), << PKCS8 >> (cle publique ou privee PKCS8) ou << PEM >> (cle publique PEM). Par defaut, OpenSSH ecrit les cles privees nouvellement creees sous son format propre, mais pour la conversion de cles publiques pour l'exportation, le format par defaut est << RFC4716 >>. Si le format specifie est << PEM >> lors de la creation ou de la mise a jour d'un type de cle privee pris en charge, la cle sera ecrite sous le format de cle privee patrimonial PEM. -N nouvelle_phrase_secrete Cette option permet de specifier la nouvelle phrase secrete. -n principals Cette option permet de specifier un ou plusieurs << principals >> (noms d'hote ou d'utilisateur) a inclure dans un certificat lors de la signature d'une cle. Plusieurs << principals >> peuvent etre specifies en les separant par des virgules (NDT : un << principal >> est une chaine arbitraire definie au niveau du serveur pour un utilisateur et devant etre presente dans le certificat du client pour que ce dernier puisse se connecter). Voir la section CERTIFICATS pour les details. -O option Specifier une option sous la forme d'une paire mot-cle/valeur. Cette derniere est specifique a l'operation que ssh-keygen doit effectuer. Une des options repertoriees dans la section CERTIFICATS peut etre specifiee ici lors de la signature des certificats. Une des options repertoriees dans la section GENERATION DES MODULI peut etre specifiee lors de la generation ou la verification des moduli. Les options repertoriees dans la section AUTHENTIFICATEUR FIDO peuvent etre specifiees lors de la generation de cles hebergees par un authentificateur FIDO. Lorsqu'on effectue des operations en rapport avec une signature a l'aide de l'option -Y, les options suivantes sont valables : hashalg=algorithme Selectionner l'algorithme de hachage a utiliser pour hacher le message a signer. Les algorithmes valables sont << sha256 >> et << sha512 >>. La valeur par defaut est<< sha512 >>. print-pubkey Afficher l'integralite de la cle publique sur la sortie standard apres verification de la signature. verify-time=horodatage Specifier une heure a utiliser a la place de l'heure actuelle pour la validation d'une signature. L'heure peut etre specifiee sous forme de date ou d'heure au format AAAAMMJJ[Z] ou AAAAMMJJHHMM[SS][Z]. Les dates et heures seront interpretees selon le fuseau horaire actuel du systeme, sauf si elles sont suffixees du caractere << Z >>, auquel cas elles seront interpretees selon le fuseau horaire UTC. Lors d'une generation d'enregistrements DNS SSHFP a partir de cles publiques a l'aide de l'option -r, les options valables sont les suivantes : hashalg=algorithme Selectionner un algorithme de hachage a utiliser pour l'affichage des enregistrements SSHFP a l'aide de l'option -D. Les algorithmes disponibles sont << sha1 >> et << sha256 >>. Par defaut, les enregistrements sont affiches en utilisant les deux algorithmes. L'option -O peut etre specifiee plusieurs fois. -P phrase_secrete Fournir la phrase secrete (l'ancienne). -p Demander de changer la phrase secrete d'un fichier de cle privee au lieu de creer une nouvelle cle privee. Le programme demandera le nom du fichier contenant la cle privee, l'ancienne phrase secrete et deux fois la nouvelle phrase secrete. -Q Tester si les cles ont ete revoquees dans une KRL. Si l'option -l est specifiee, le contenu de la KRL sera affiche. -q Rendre silencieux ssh-keygen. -R nom_hote | [nom_hote]:port Supprimer d'un fichier known_hosts toutes les cles appartenant au nom_hote specifie (accompagne eventuellement du numero de port). Cette option s'avere utile pour supprimer des hotes haches (voir l'option -H ci-dessus). -r nom_hote Afficher l'enregistrement de ressource d'empreinte SSHFP nomme nom_hote pour le fichier de cle publique specifie. -s cle_CA Certifier (signer) une cle publique a l'aide de la cle de CA specifiee. Voir la section CERTIFICATS pour les details. A la generation d'une KRL (liste de revocation de cles, NDT), l'option -s permet de specifier le chemin d'un fichier de cle publique de CA utilise pour revoquer des certificats directement a l'aide du numero de serie ou de l'identifiant de la cle. Voir la section LISTES DE REVOCATION DE CLES pour les details. -t ecdsa | ecdsa-sk | ed25519 | ed25519-sk | rsa Cette option permet de specifier le type de la cle a creer. Les valeurs possibles sont << ecdsa >>, << ecdsa-sk >>, << ed25519 >> (par defaut), << ed25519-sk >> ou << rsa >>. Cette option permet aussi de specifier le type de signature souhaite pour la signature de certificats a l'aide d'une cle de CA RSA. Les types de signature RSA disponibles sont << ssh-rsa >> (signatures SHA1, non recommande), << rsa-sha2-256 >> et << rsa- sha2-512 >> (par defaut pour les cles RSA). -U Utilisee en combinaison avec -s ou -Y sign, cette option indique qu'une cle de CA reside dans un agent ssh-agent(1). Voir la section CERTIFICATS pour plus d'informations. -u Mettre a jour une KRL. Si cette option est utilisee en combinaison avec l'option -k, au lieu de creer une nouvelle KRL, les cles listees sur la ligne de commande sont ajoutees a la KRL existante. -V intervalle_validite Cette option permet de specifier un intervalle de validite lors d'une signature de certificat. Un intervalle de validite peut etre une simple date, indiquant que le certificat est valable a partir de maintenant et jusqu'a cette date, ou peut comporter deux dates separees par un << : >> pour indiquer un intervalle de validite explicite. L'heure de debut peut etre specifiee par : o La chaine << always >> pour indiquer que le certificat n'a pas de date de debut de validite specifiee. o Une date ou heure dans le fuseau horaire du systeme et indiquee sous la forme AAAAMMDD ou AAAAMMDDHHMM[SS]. o Une date ou heure dans le fuseau horaire UTC et indiquee sous la forme AAAAMMJJZ ou AAAAMMJJHHMM[SS]Z. o Une heure relative anterieure a l'heure systeme actuelle et comportant un signe moins suivi d'un intervalle dans le format decrit dans la section FORMATS DE TEMPS de sshd_config(5). o Un nombre de secondes apres l'Epoque (1er janvier 1970 00:00:00 UTC) sous la forme d'un nombre hexadecimal commencant par << 0x >>. L'heure de fin peut etre specifiee de maniere similaire a l'heure de debut : o La chaine << forever >> pour indiquer que le certificat n'a pas de date de fin de validite specifiee. o Une date ou heure dans le fuseau horaire du systeme et indiquee sous la forme AAAAMMDD ou AAAAMMDDHHMM[SS]. o Une date ou heure dans le fuseau horaire UTC et indiquee sous la forme AAAAMMJJZ ou AAAAMMJJHHMM[SS]Z. o Une heure relative posterieure a l'heure systeme actuelle et comportant un signe plus suivi d'un intervalle dans le format decrit dans la section FORMATS DE TEMPS de sshd_config(5). o Un nombre de secondes apres l'Epoque (1er janvier 1970 00:00:00 UTC) sous la forme d'un nombre hexadecimal commencant par << 0x >>. Par exemple : +52w1d Le certificat est valable a partir de maintenant et pour une duree de 52 semaines et 1 jour. -4w:+4w Le certificat etait valable les quatre dernieres semaines et le sera encore pendant les quatre prochaines semaines. 20100101123000:20110101123000 Le certificat est valable du 1er janvier 2010 a 12 h 30 au 1er janvier 2011 a 12 h 30. 20100101123000Z:20110101123000Z Identique, mais exprime en temps universel UTC. -1d:20110101 Le certificat est valable depuis hier et jusqu'au 1er janvier 2011 a minuit. 0x1:0x2000000000 Le certificat est valable depuis le tout debut de 1970 et jusqu'a mai 2033. -1m:forever Le certificat est valable depuis 1 minute et n'expirera jamais. -v Mode prolixe. Si cette option est utilisee, ssh-keygen affichera des messages de debogage a propos de son execution. Cette option s'avere utile pour le debogage de la generation des moduli. Specifier plusieurs fois l'option -v (au maximum 3) augmente la prolixite. -w fournisseur Cette option permet de specifier le chemin d'une bibliotheque qui sera utilisee pour la creation de cles hebergees par un authentificateur FIDO, outrepassant par la meme le comportement par defaut consistant a utiliser la prise en charge interne de USB HID. -Y find-principals Cette option permet de trouver le(s) << principal(s) >> associes a la cle publique d'une signature specifiee a l'aide de l'option -s dans un fichier de signataires autorises specifie a l'aide de l'option -f. Le format du fichier de signataires autorises est documente dans la section SIGNATAIRES AUTORISES ci-dessous. Si un ou plusieurs << principals >> correspondants sont trouves, ils sont renvoyes sur la sortie standard. -Y match-principals Trouver le << principal >> correspondant au nom de principal fourni a l'aide de l'option -I dans le fichier de signataires autorises specifie a l'aide de l'option -f. Si un ou plusieurs << principals >> qui correspondent sont trouves, ils sont renvoyes sur la sortie standard. -Y check-novalidate Verifier qu'une signature generee a l'aide de ssh-keygen -Y sign possede une structure valable. Cette verification ne garantit pas qu'une signature provient d'un signataire autorise. Lors d'une verification de signature, ssh-keygen peut recevoir un message sur l'entree standard et un espace de noms de signature a l'aide de l'option -n. Le nom d'un fichier contenant la signature correspondante doit aussi etre fourni a l'aide de l'option -s. Si la signature est testee avec succes, ssh-keygen renvoie un code de retour de 0. -Y sign Signer de maniere cryptographique un fichier ou des donnees quelconques en utilisant une cle SSH. Lors d'une signature, ssh-keygen recoit zero ou plusieurs noms de fichier sur la ligne de commande -- si aucun nom de fichier n'est specifie, ssh-keygen signera les donnees presentees sur l'entree standard. Les signatures sont ecrites a l'emplacement du fichier d'entree avec l'extension << .sig >> ou sur la sortie standard si le message a signer a ete lu sur l'entree standard. La cle utilisee pour la signature est specifiee a l'aide de l'option -f et peut correspondre a une cle privee ou a une cle publique, la contrepartie privee etant fournie dans ce dernier cas par l'agent ssh-agent(1). Pour eviter de confondre des signatures entre differents domaines d'utilisation (signature d'un fichier vs signature d'un courriel par exemple), un espace de noms de signature additionnel doit etre specifie a l'aide de l'option -n. Les espaces de noms sont des chaines arbitraires pouvant contenir << fichier >> pour la signature d'un fichier ou << courriel >> pour la signature d'un email. Pour une utilisation personnalisee, il est recommande d'utiliser des noms suivant un motif ESPACE_NOMS@VOTRE_DOMAINE pour generer des espaces de noms depourvus d'ambiguite. -Y verify Demander la verification d'une signature generee en utilisant la commande ssh-keygen -Y sign comme decrit ci-dessus. Lors d'une verification de signature, ssh-keygen peut recevoir un message sur l'entree standard et un espace de noms de signature a l'aide de l'option -n. Le nom d'un fichier contenant la signature correspondante doit aussi etre fourni a l'aide de l'option -s, accompagne de l'identite du signataire a l'aide de l'option -I et d'une liste de signataires autorises a l'aide de l'option -f. Le format du fichier des signataires autorises est documente dans la section SIGNATAIRES AUTORISES ci-dessous. Le nom d'un fichier contenant la liste des cles revoquees peut etre fourni a l'aide de l'option -r. Le fichier des revocations de cles peut etre une KRL (Key Revocation List) ou une liste de cles publiques (une par ligne). ssh-keygen renvoie un code de retour de 0 en cas de verification avec succes par un signataire autorise. -y Cette option permet de lire un fichier prive au format OpenSSH et d'afficher une cle publique OpenSSH sur la sortie standard. -Z algo_chiffrement Cette option permet de specifier l'algorithme a utiliser pour le chiffrement d'un fichier de cle privee au format OpenSSH. La liste des algorithmes disponibles peut etre obtenue a l'aide de la commande << ssh -Q cipher >>. L'algorithme par defaut est << aes256-ctr >>. -z numero_serie Cette option permet de specifier un numero de serie a inclure dans le certificat afin de le differencier des autres certificats du meme CA. Si le numero_serie est prefixe avec le caractere << + >>, il sera incremente pour chaque certificat signe sur une seule ligne de commande. Le numero de serie par defaut est 0. Lorsqu'on genere une KRL, l'option -z permet de specifier le numero de version de cette KRL. GENERATION DES MODULI ssh-keygen permet de generer des groupes pour le protocole Diffie-Hellman Group Exchange (DH-GEX). La generation de ces groupes est un processus en deux etapes. D'abord, les nombres premiers candidats sont generes en utilisant un processus rapide mais gourmand en memoire. Ces nombres premiers candidats sont alors testes pour leur pertinence (processus utilisant intensement le CPU). La generation des nombres premiers est effectuee en utilisant l'option -M generate. La longueur souhaitee des nombres premiers peut etre specifiee a l'aide de l'option -O bits. Par exemple : # ssh-keygen -M generate -O bits=2048 moduli-2048.candidates Par defaut, la recherche de nombres premiers debute par une valeur aleatoire dans l'intervalle correspondant a la longueur souhaitee, mais il est possible de modifier cette valeur a l'aide de l'option -O start qui permet d'indiquer un point de depart different (en hexadecimal). Lorsqu'un jeu de candidats a ete genere, ils doivent etre testes pour verifier s'ils conviennent. Pour ce faire, on utilise l'option -M screen. Dans ce mode, ssh-keygen va lire la liste des candidats sur l'entree standard (ou dans un fichier specifie a l'aide de l'option -f). Par exemple : # ssh-keygen -M screen -f moduli-2048.candidates moduli-2048 Par defaut, chaque candidat subit 100 tests de primalite. Ce nombre peut etre modifie a l'aide de l'option -O prime-tests. La valeur de generateur DH sera choisie automatiquement pour le nombre premier considere. Si un generateur specifique est souhaite, il sera specifie a l'aide de l'option -O generator. Les valeurs de generateur valables sont 2, 3 et 5. Les groupes DH testes peuvent etre installes dans /etc/ssh/moduli. Il est important que ce fichier contienne des moduli dans une plage de longueurs en bits. Plusieurs options sont disponibles pour la generation et la verification des moduli par l'intermediaire de l'option -O : lines=nombre Quitter apres avoir verifie le nombre de lignes specifie lors du test des candidats DH. start-line=numero_ligne Debuter la verification au numero de ligne specifie pour le test des candidats DH. checkpoint=nom_fichier Ecrire la derniere ligne traitee dans le fichier specifie lors du test des candidats DH. Cela permet de sauter les lignes du fichier d'entree qui ont deja ete traitees si la tache est relancee. memory=megaoctets Cette option permet de specifier la quantite de memoire a utiliser (en megaoctets) pour la generation des moduli pour DH- GEX (Diffie-Hellman group exchange). start=valeur_hexadecimale Specifier un point de depart (en hexadecimal) pour la generation des moduli pour DH-GEX (Diffie-Hellman group exchange). generator=valeur Specifier le generateur souhaite (en decimal) lors du test des moduli candidats pour DH-GEX (Diffie-Hellman group exchange). CERTIFICATS ssh-keygen prend en charge la signature des cles pour produire des certificats qui pourront etre utilises pour l'authentification des utilisateurs ou des hotes. Un certificat comporte une cle publique, des informations relatives a l'identite, zero ou plusieurs noms de << principal >> (utilisateur ou hote) et un jeu d'options signes par une cle d'autorite de certification (CA). Au lieu de devoir considerer comme fiables plusieurs cles d'utilisateur ou d'hote, les clients ou les serveurs peuvent alors se contenter de ne considerer comme fiable que la cle de CA et de verifier sa signature sur un certificat. Notez que les certificats OpenSSH possedent un format different (et beaucoup plus simple) de celui des certificats X509 utilises dans ssl(8). ssh-keygen prend en charge deux types de certificat : utilisateur et hote. Les certificats utilisateur authentifient les utilisateurs aupres des serveurs, alors que les certificats d'hote authentifient les hotes serveur aupres des utilisateurs. Pour generer un certificat utilisateur : $ ssh-keygen -s /chemin/vers/cle_CA -I key_id /chemin/vers/cle_utilisateur.pub Le certificat obtenu sera place dans /chemin/vers/cle_utilisateur-cert.pub. La creation d'un certificat d'hote necessite l'option -h : $ ssh-keygen -s /chemin/vers/cle_CA -I id_cle -h /chemin/vers/cle_hote.pub Le certificat d'hote obtenu sera place dans /chemin/vers/cle_hote-cert.pub. Il est possible de signer en utilisant une cle de CA stockee dans un jeton PKCS#11 en fournissant la bibliotheque de jeton a l'aide de l'option -D et en identifiant la cle de CA en fournissant sa partie publique comme argument de l'option -s : $ ssh-keygen -s cle_CA.pub -D libpkcs11.so -I id_cle cle_utilisateur.pub De meme, il est possible de faire heberger la cle de CA par un agent ssh-agent(1) en utilisant l'option -U ; la encore, la cle de CA doit etre identifiee par sa partie publique. $ ssh-keygen -Us cle_CA.pub -I id_cle cle_utilisateur.pub Dans tous les cas, id_cle est un << identifiant de cle >> qui est conserve par le serveur lorsque le certificat est utilise pour l'authentification. La validite des certificats peut etre limitee a un jeu de noms de << principal >> (utilisateur/hote). Par defaut, les certificats generes sont valables pour tous les utilisateurs ou hotes. Pour generer un certificat valable pour un jeu de << principals >> specifie : $ ssh-keygen -s cle_CA -I id_cle -n utilisateur1,utilisateur2 cle_utilisateur.pub $ ssh-keygen -s cle_CA -I id_cle -h -n hote.domaine cle_hote.pub D'autres limitations de la validite et de l'utilisation des certificats utilisateur peuvent etre specifiees a l'aide d'options de certificat. Une option de certificat pourra desactiver des fonctionnalites de la session SSH, pourra n'etre valable que si presentee depuis des adresses source particulieres ou pourra forcer l'utilisation d'une commande specifique. Les option disponibles pour les certificats utilisateur sont : clear Supprimer toutes les permissions activees. Cette option s'avere utile pour supprimer le jeu de permissions par defaut de facon a pouvoir ajouter des permissions individuellement. critical:nom[=contenu] extension:nom[=contenu] Inclure une option ou extension critique de certificat arbitraire. Le nom specifie doit contenir un suffixe de domaine comme << nom@example.com >>. Si contenu est specifie, il est inclus comme contenu de l'extension/option codee en tant que chaine ; dans le cas contraire, l'extension/option est creee sans contenu (ce qui indique en general qu'il s'agit d'un drapeau). Un client ou un serveur qui ne reconnait pas une extension peut l'ignorer, attendu que les options critiques inconnues entraineront le rejet du certificat. force-command=commande Forcer l'execution de la commande a la place de toute commande ou tout interpreteur de commande specifie par l'utilisateur quand le certificat est utilise pour l'authentification. no-agent-forwarding Desactiver la redirection de ssh-agent(1) (autorisee par defaut). no-port-forwarding Desactiver la redirection de port (autorisee par defaut). no-pty Desactiver l'allocation de pseudo-terminal (autorisee par defaut). no-user-rc Desactiver l'execution de ~/.ssh/rc par sshd(8) (autorisee par defaut). no-x11-forwarding Desactiver la redirection de X11 (autorisee par defaut). permit-agent-forwarding Autoriser la redirection de ssh-agent(1). permit-port-forwarding Autoriser la redirection de port. permit-pty Autoriser l'allocation de pseudo-terminal. permit-user-rc Autoriser l'execution de ~/.ssh/rc par sshd(8). permit-X11-forwarding Autoriser la redirection de X11. no-touch-required Ne pas exiger que les signatures effectuees a l'aide de cette cle incluent la preuve de la presence de l'utilisateur (par exemple en exigeant que l'utilisateur touche l'authentificateur). Cette option n'est pertinente que pour les algorithmes d'authentificateur FIDO ecdsa-sk et ed25519-sk. source-address=liste_adresses Restreindre les adresses source a partir desquelles le certificat est considere comme valable. liste_adresses est une liste, separee par des virgules, d'une ou plusieurs paires adresse/masque reseau au format CIDR. verify-required Exiger que les signatures effectuees en utilisant cette cle indiquent que l'utilisateur a ete verifie au prealable. Cette option n'est pertinente que pour les algorithmes d'authentificateur FIDO ecdsa-sk et ed25519-sk. La seule methode de verification prise en charge a l'heure actuelle est l'authentification par code PIN, mais il est possible que d'autres methodes soient prises en charge dans le futur. A l'heure actuelle, aucune option standard n'est valable pour les cles d'hote. Pour finir, un certificat peut etre defini avec une duree de validite. A cet effet, l'option -V permet de specifier une heure de debut et une heure de fin de validite pour le certificat. Un certificat presente en dehors de cet intervalle de temps sera considere comme non valable. Par defaut, les certificats sont valables depuis l'Epoque UNIX jusqu'a un futur lointain. Pour les certificats servant a l'authentification d'un utilisateur ou d'un hote, la cle publique de CA doit etre consideree comme fiable par sshd(8) ou ssh(1). Veuillez consulter ces pages du manuel pour les details. AUTHENTIFICATEUR FIDO ssh-keygen peut generer des cles hebergees par un authentificateur FIDO ; ces dernieres peuvent alors etre utilisees quasiment comme tout autre type de cle pris en charge par OpenSSH, pourvu que l'authentificateur materiel soit branche lorsque les cles sont utilisees. En general, l'authentificateur FIDO a besoin que l'utilisateur le touche ou le tapote pour autoriser explicitement des operations. Les cles FIDO comportent deux parties : une partie gestion de cle stockee dans le fichier de cle privee sur disque, et une cle privee par dispositif unique pour chaque authentificateur FIDO et qui ne peut pas etre exportee depuis l'authentificateur materiel. Ces deux parties sont combinees par le materiel lors de l'authentification pour produire la cle reelle qui sera utilisee pour signer les epreuves d'authentification. Les types de cle pris en charge sont ecdsa-sk et ed25519-sk. Les options valables pour les cles FIDO sont : application Remplacer la chaine FIDO par defaut application/origine de << ssh: >>. Cette option peut s'averer utile pour generer des cles residentes specifiques a un hote ou un domaine. La chaine application specifiee doit commencer par << ssh: >>. challenge=chemin Cette option permet de specifier le chemin d'une chaine d'epreuve qui sera transmise a l'authentificateur FIDO pendant la generation de la cle. La chaine d'epreuve peut etre utilisee en tant que partie d'un protocole inhabituel pour l'inscription d'une cle (une epreuve aleatoire est utilisee par defaut). device Specifier explicitement un dispositif fido(4) a utiliser au lieu de laisser l'intergiciel de l'authentificateur en choisir un. no-touch-required Cette option permet d'indiquer que la cle privee generee ne requiert pas de contact physique (presence de l'utilisateur) pour effectuer des signatures. Notez que par defaut, sshd(8) refusera de telles signatures, sauf mention contraire a l'aide d'une option authorized_keys. resident Cette option indique que la gestion de la cle doit etre stockee sur l'authentificateur FIDO lui-meme, ce qui facilite l'utilisation de l'authentificateur sur plusieurs ordinateurs. Les cles residentes peuvent etre prises en charge par les authentificateurs FIDO2 et il est en general necessaire de definir le code PIN sur l'authentificateur avant la generation. Les cles residentes peuvent etre chargees a partir de l'authentificateur a l'aide de ssh-add(1). Stocker les deux parties d'une cle sur un authentificateur FIDO augmente la probabilite qu'un attaquant parvienne a utiliser un dispositif d'authentification vole. user Cette option permet de specifier un nom d'utilisateur a associer a une cle residente, remplacant par la meme le nom d'utilisateur par defaut vide. Specifier un nom d'utilisateur peut s'averer utile lors de la generation de cles residentes multiples pour le meme nom d'application. verify-required Cette option indique que cette cle privee requiert une verification de l'utilisateur pour chaque signature. Tous les authentificateurs FIDO ne prennent pas en charge cette option. Actuellement, l'authentification par code PIN est la seule methode de verification prise en charge, mais d'autres methodes seront peut-etre prises en charge dans le futur. write-attestation=chemin Cette option peut etre utilisee a la generation de la cle pour enregistrer les donnees d'attestation renvoyees par les authentificateurs FIDO lors de la generation de la cle. Ces informations sont potentiellement sensibles et elles sont ignorees par defaut. LISTES DE REVOCATION DE CLES ssh-keygen peut gerer les listes de revocation de cles au format OpenSSH (KRL). Ces fichiers binaires specifient des cles ou certificats devant etre revoques en utilisant un format compact ne necessitant pas plus d'un bit par certificat si ce dernier est revoque en fonction de son numero de serie. Les KRL peuvent etre generees en utilisant l'option -k. Cette option lit un ou plusieurs fichiers specifies sur la ligne de commande et genere une nouvelle KRL. Les fichiers peuvent contenir soit une specification KRL (voir ci-apres), soit des cles publiques (une par ligne). Les cles publiques simples sont revoquees en listant leurs hachages ou contenus dans la KRL et les certificats le sont en specifiant leurs numeros de serie ou leurs ID de cle (si le numero de serie est egal a zero ou indisponible). Revoquer des cles en utilisant une specification KRL permet de controler explicitement le type d'enregistrement utilise pour revoquer les cles, et permet de revoquer directement des certificats en fonction de leurs numeros de serie ou de leurs ID de cle sans avoir l'ensemble du certificat sous la main. Une specification KRL se compose de lignes contenant une des directives suivantes suivie d'un deux-points << : >> et d'informations specifiques a la directive. serial: numero_serie[-numero_serie] Revoque le certificat qui possede le numero de serie specifie. Les numeros de serie sont des valeurs differentes de zero sur 64 bits qui peuvent etre exprimees en decimal, en hexadecimal ou en octal. Si deux numeros de serie sont specifies separes par un trait d'union, l'intervalle de numeros de serie qu'ils composent, bornes comprises, sera revoque. La cle de CA doit avoir ete specifiee sur la ligne de commande de ssh-keygen a l'aide de l'option -s. id: ID_cle Revoque le certificat possedant la chaine ID_cle specifiee. La cle de CA doit avoir ete specifiee sur la ligne de commande de ssh-keygen a l'aide de l'option -s. key: cle_publique Revoque la cle specifiee. S'il s'agit d'un certificat, il sera revoque comme une simple cle publique. sha1: cle_publique Revoque la cle specifiee en incluant son hachage SHA1 dans la KRL. sha256: cle_publique Revoque la cle specifiee en incluant son hachage SHA256 dans la KRL. Les KRL qui revoquent des cles en fonction de leur hachage SHA256 ne sont pas prises en charge par les versions d'OpenSSH anterieures a 7.9. hash: empreinte Revoque une cle en utilisant un hachage d'empreinte tel qu'obtenu a partir d'un message de journalisation d'authentification de sshd(8) ou a l'aide de l'option -l de ssh-keygen. Seules les empreintes SHA256 sont prises en charge ici et les KRL resultantes ne sont pas prises en charge par les versions d'OpenSSH anterieures a 7.9. Les KRL peuvent etre mises a jour en utilisant l'option -u en plus de l'option -k. Lorsque cette option est utilisee, les cles listees sur la ligne de commande sont fusionnees dans la KRL en s'ajoutant a celles qui y sont deja. Il est aussi possible, pour une KRL donnee, de verifier si elle revoque une ou des cles particulieres. L'option -Q permet de questionner une KRL existante en verifiant chacune des cles specifiees sur la ligne de commande. Si une cle specifiee sur la ligne de commande a ete revoquee (ou si une erreur se produit), ssh-keygen quittera avec un code de retour different de zero. Un code de retour de zero ne sera renvoye que si aucune cle n'a ete revoquee. SIGNATAIRES AUTORISES Lors de la verification des signatures, ssh-keygen utilise une simple liste d'identites et de cles pour determiner si une signature provient d'une source autorisee. Ce fichier des << signataires autorises >> utilise un format calque sur le FORMAT DU FICHIER AUTHORIZED_KEYS decrit dans sshd(8). Chaque ligne du fichier contient les champs suivants separes par des espaces : principals, options, keytype, base64-encoded key. Les lignes vides et les lignes commencant par un << # >> sont ignorees et considerees comme des commentaires. Le champ << principals >> est une liste de motifs (voir MOTIFS dans ssh_config(5)) contenant un ou plusieurs motifs d'identite UTILISATEUR@DOMAINE separes par des virgules et acceptes pour les signatures. Lors de la verification, l'identite presentee a l'aide de l'option -I doit correspondre a un motif de << principals >> pour que la cle correspondante soit consideree comme acceptable pour la verification. Le champ options (si present) contient des specifications d'option separees par des virgules. Aucune espace n'est permise, sauf si elle est entouree de guillemets hauts doubles. Les specifications d'option suivantes sont prises en charge (notez que les noms d'option sont insensibles a la casse) : cert-authority Indique que cette cle est consideree comme une autorite de certification (CA) et que les certificats signes par cette CA peuvent etre acceptes pour la verification. namespaces=liste_espaces_noms Specifie une liste de motifs d'espaces de noms acceptes pour cette cle. Si cette option est presente, l'espace de noms de signature integre a l'objet signature et presente sur la ligne de commande de verification doit correspondre a la liste specifiee pour que la cle soit consideree comme acceptable. valid-after=horodatage Indique que la cle est valable a partir de l'horodatage specifie qui peut etre une date ou une heure au format AAAAMMJJ[Z] ou AAAAMMJJHHMM[SS][Z]. Les dates et heures sont interpretees dans le fuseau horaire actuel du systeme, sauf si elles sont suffixees du caractere << Z >>, auquel cas elles sont interpretees dans le fuseau horaire UTC. valid-before=horodatage Indique que la cle est valable jusqu'a l'horodatage specifie. Lors de la verification des signatures faites par des certificats, le nom de << principal >> attendu doit correspondre a la fois au motif de << principals >> enregistre dans le fichier des signataires autorises et aux << principals >> integres dans le certificat lui-meme. Un exemple de fichier des signataires autorises : # Commentaires autorises en debut de ligne utilisateur1@example.com,utilisateur2@example.com ssh-rsa AAAAX1... # Une autorite de certification approuvee pour tous les << principals >> d'un domaine. *@example.com cert-authority ssh-ed25519 AAAB4... # Une cle qui n'est acceptee que pour signer des fichiers. utilisateur2@example.com namespaces="fichier" ssh-ed25519 AAA41... ENVIRONNEMENT SSH_SK_PROVIDER Specifie le chemin d'une bibliotheque a utiliser pour le chargement des cles hebergees par un authentificateur FIDO, outrepassant ainsi le comportement par defaut consistant a utiliser le support USB HID integre. FICHIERS ~/.ssh/id_ecdsa ~/.ssh/id_ecdsa_sk ~/.ssh/id_ed25519 ~/.ssh/id_ed25519_sk ~/.ssh/id_rsa Ces fichiers contiennent l'identite d'authentification de l'utilisateur ECDSA, ECDSA hebergee par un authentificateur, Ed25519, Ed25519 hebergee par un authentificateur ou RSA. Ces fichiers ne doivent etre accessibles en lecture que pour l'utilisateur. Il est possible de specifier une phrase secrete lors de la generation de la cle ; cette phrase secrete sera utilisee pour chiffrer la partie privee de ce fichier en utilisant l'algorithme AES 128 bits. Ce fichier n'est pas automatiquement consulte par ssh-keygen, mais il correspond au fichier par defaut pour la cle privee. ssh(1) lit ce fichier lorsqu'une tentative de connexion est effectuee. ~/.ssh/id_ecdsa.pub ~/.ssh/id_ecdsa_sk.pub ~/.ssh/id_ed25519.pub ~/.ssh/id_ed25519_sk.pub ~/.ssh/id_rsa.pub Ces fichiers contiennent la cle publique d'authentification ECDSA, ECDSA hebergee par un authentificateur, Ed25519, Ed25519 hebergee par un authentificateur ou RSA. Le contenu de ces fichiers doit etre ajoute au fichier ~/.ssh/authorized_keys de toutes les machines auxquelles l'utilisateur souhaite se connecter en utilisant une authentification par cle publique. Il n'est pas necessaire de garder secret le contenu de ce fichier. /etc/ssh/moduli Ce fichier contient les groupes Diffie-Hellman utilises pour DH- GEX (Diffie-Hellman group exchange). Le format de ce fichier est decrit dans moduli(5). VOIR AUSSI ssh(1), ssh-add(1), ssh-agent(1), moduli(5), sshd(8) << The Secure Shell (SSH) Public Key File Format >>, RFC 4716, 2006. AUTEURS OpenSSH est un derive de la version originale et libre 1.2.12 de ssh par Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt et Dug Song ont corrige de nombreux bogues, rajoute de nouvelles fonctionnalites et cree OpenSSH. Markus Friedl a contribue a la prise en charge des versions 1.5 et 2.0 du protocole SSH. TRADUCTION La traduction francaise de cette page de manuel a ete creee par Lucien Gentis Cette traduction est une documentation libre ; veuillez vous reporter a la GNU General Public License version 3: https://www.gnu.org/licenses/gpl-3.0.html concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITE LEGALE. Si vous decouvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message a debian-l10n-french@lists.debian.org Linux 6.13.7-arch1-1 $Mdocdate: 17 aout 2024 $ Linux 6.13.7-arch1-1