SSH-ADD(1)

NOM
ssh-add - Ajouter des identités de clé privée dans l'agent d'authentification d’OpenSSH

SYNOPSIS
ssh-add [-CcDdKkLlqvXx] [-E hachage_empreinte] [-H fichier_clé_hôte] [-h restriction_destination] [-S fournisseur] [-t durée_de_vie] [fichier ...]
ssh-add -s pkcs11 [-Cv] [certificat ...]
ssh-add -e pkcs11
ssh-add -T clé_publique ...

DESCRIPTION
ssh-add ajoute des identités de clé privée dans l'agent d'authentification ssh-agent(1). Lorsqu'il est exécuté sans argument, il ajoute les fichiers ~/.ssh/id_rsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519 et ~/.ssh/id_ed25519_sk. Après le chargement d'une clé privée, ssh-add tente de charger l'information du certificat correspondant depuis le fichier dont le nom est obtenu en suffixant le nom du fichier de clé privée avec -cert.pub. Il est possible de spécifier des noms de fichiers différents sur la ligne de commande.

Si l'un des fichiers nécessite une phrase secrète, ssh-add la demandera à l'utilisateur. La phrase secrète est lue depuis le terminal de l'utilisateur. ssh-add tentera de rejouer la dernière phrase secrète si plusieurs fichiers d’identité sont fournis.

L'agent d'authentification doit être en cours d'exécution et la variable d'environnement SSH_AUTH_SOCK doit contenir le nom de son socket pour que ssh-add puisse fonctionner.

Les options sont les suivantes :

-C  Ne traiter que les certificats et délaisser les clés simples lors de l’ajout ou de la suppression de clés de l’agent.

-c  Indiquer que les identités ajoutées devront faire l’objet d’une confirmation avant d'être utilisées pour l'authentification. La confirmation est réalisée à l’aide du programme ssh-askpass(1). Au lieu d’afficher un texte dans l'interface, une confirmation fructueuse est signalée par un code de retour de 0 de ssh-askpass(1).

-D  Supprimer toutes les identités de l'agent.

-d  Supprimer des identités de l'agent au lieu d’en ajouter. Si ssh-add est exécuté sans argument, les clés des identités par défaut et les certificats correspondants sont supprimés. Sinon, la liste d'arguments est interprétée comme une liste de chemins de fichiers de clé publique pour spécifier les clés et certificats à supprimer de l'agent. Si aucune clé publique n'est trouvée dans les chemins spécifiés, ssh-add ajoutera .pub à ces chemins et relancera la tentative de suppression. Si la liste d’arguments est « - », ssh-add lira les clés publiques à supprimer sur l’entrée standard.

-E hachage_empreinte
    Cette option permet de spécifier l’algorithme de hachage utilisé pour l’affichage des empreintes de clé. Les options valables sont « md5 » et « sha256 ». La valeur par défaut est « sha256 ».

-e pkcs11
    Supprimer les clés fournies par la bibliothèque partagée PKCS#11 pkcs11.

-H fichier_clé_hôte
    Cette option permet de spécifier un fichier des hôtes connus pour rechercher des clés d’hôte lorsque les clés de l’hôte de destination sont restreintes à l’aide de l’option -h. Spécifier cette option plusieurs fois permet d’effectuer la recherche dans plusieurs fichiers. Si aucun fichier n’est spécifié, ssh-add utilisera les fichiers des hôtes connus par défaut de ssh_config(5) : ~/.ssh/known_hosts, ~/.ssh/known_hosts2, /etc/ssh/ssh_known_hosts et /etc/ssh/ssh_known_hosts2.

-h restriction_destination
    Lors de l’ajout de clés, restreindre leur utilisation à des hôtes spécifiques ou à certaines destinations.

    Les restrictions de destination de la forme « [utilisateur@]nom_hôte_destination » imposent l’utilisation de la clé depuis l’hôte d’origine (celui qui exécute ssh-agent(1)) vers l’hôte de destination indiqué, optionnellement préfixé du nom d’utilisateur.

    Les restrictions de la forme « nom_hôte_source>[utilisateur@]nom_hôte_destination » imposent, pour utiliser une clé disponible dans un ssh-agent(1) redirigé, de passer par un hôte particulier (spécifié par « src-hostname ») pour s’authentifier auprès d’un hôte final (spécifié par « dst-hostname »).

    Il est possible d’ajouter plusieurs restrictions de destination lors d’un chargement de clé. Lors d’une tentative d’authentification avec une clé qui fait l’objet de restrictions de destination, l’ensemble du cheminement de la connexion, y compris la redirection de l’agent ssh-agent(1), est testé vis-à-vis de ces restrictions et chaque saut doit être autorisé pour que la tentative aboutisse. Par exemple, si une clé est redirigée vers l’hôte distant « hôte_b » et est utilisée pour un authentification auprès de l’hôte « hôte_c », l’opération ne réussira que si « host-b » a été autorisé depuis l’hôte d’origine et si le saut subséquent « hôte_b>hôte_c » est aussi autorisé par les restrictions de destination.

    Les hôtes sont identifiés par leur clé d’hôte et sont recherchés dans les fichiers d’hôtes connus par ssh-add. Il est possible d’utiliser des motifs avec caractères génériques pour les noms d’hôte et les clés d’hôte sous forme de certificat sont prises en charge. Par défaut, les clés ajoutées par ssh-add ne présentent pas de restrictions de destination.

    Les restrictions de destination sont prises en charge depuis la version 8.9 d’OpenSSH. Cette prise en charge est requise à la fois au niveau du client SSH distant et du serveur lorsqu’on utilise des clés avec restrictions de destination sur un canal d’agent ssh-agent(1) redirigé.

    Il est aussi important de noter que les restrictions de destination ne peuvent être appliquées par ssh-agent(1) que si une clé est utilisée ou s’il est redirigé par un ssh(1) coopératif. En particulier, elles n’empêcheront pas un attaquant ayant accès à un SSH_AUTH_SOCK distant de le rediriger à nouveau et de l’utiliser sur un autre hôte (mais seulement vers une destination autorisée).

-K  Charger les clés résidentes à partir d’un authentificateur FIDO.

-k  Lors du chargement de clés dans l’agent ou de suppressions de clés de l’agent, ne traiter que les clés privées simples et non les certificats.

-L  Lister les paramètres de clés publiques de toutes les identités actuellement présentes dans l'agent.

-l  Lister les empreintes de toutes les identités actuellement présentes dans l'agent.

-q  Mode silencieux après une opération réussie.

-S fournisseur
    Cette option permet de spécifier le chemin d’une bibliothèque qui sera utilisée lors de l’ajout de clés hébergées par un authentificateur FIDO ; elle outrepasse le comportement par défaut consistant à utiliser la prise en charge interne de USB HID.

-s pkcs11
    Cette option permet d’ajouter des clés fournies par la bibliothèque partagée PKCS#11 pkcs11. Il est possible de spécifier des fichiers de certificat à l’aide d’arguments sur la ligne de commande. S’ils sont présents, ils seront chargés dans l’agent en utilisant toute clé privée correspondante chargée depuis le jeton PKCS#11.

-T clé_publique ...
    Cette option permet de tester si les clés privées qui correspondent aux fichiers clé_publique spécifiés sont utilisables, en effectuant des opérations de signature et de vérifications sur chacune d’entre elles.

-t durée_de_vie
    Cette option permet de définir une durée de vie maximale lors de l'ajout d’identités dans l'agent. La durée de vie peut être spécifiée en secondes ou dans un format spécifié dans sshd_config(5).

-v  Mode prolixe. Cette option permet de demander à ssh-add d’afficher des messages de débogage à propos de son exécution. Cela s’avère utile pour déboguer les problèmes. Plusieurs options -v (au maximum 3) augmentent le prolixité.

-X  Déverrouiller l'agent.

-x  Verrouiller l'agent avec un mot de passe.

ENVIRONNEMENT

DISPLAY, SSH_ASKPASS et SSH_ASKPASS_REQUIRE
    Si ssh-add a besoin d'une phrase secrète, il la lira sur le terminal actif s'il a été lancé dans un terminal. Si ssh-add n'a aucun terminal associé alors que DISPLAY et SSH_ASKPASS sont définies, il exécutera le programme spécifié par SSH_ASKPASS (par défaut « ssh-askpass ») et ouvrira une fenêtre X11 pour lire la phrase secrète. Cela s’avère particulièrement utile lors de l'appel de ssh-add depuis un fichier .xsession ou un script similaire.

    SSH_ASKPASS_REQUIRE permet de contrôler plus finement l’utilisation d’un programme askpass. Si cette variable est définie à « never », ssh-add n’en utilisera pas. Si elle est définie à « prefer », ssh-add préférera utiliser le programme askpass plutôt que le terminal pour demander un mot de passe. Enfin, si la variable est définie à « force », le programme askpass sera utilisé pour toutes les entrées de phrase secrète, que DISPLAY soit définie ou non.

SSH_AUTH_SOCK
    Identifie le chemin du socket de domaine UNIX utilisé pour communiquer avec l’agent.

SSH_SK_PROVIDER
    Cette variable spécifie le chemin d’une bibliothèque qui sera utilisée lors de l’ajout de clés hébergées par un authentificateur FIDO ; elle outrepasse le comportement par défaut consistant à utiliser la prise en charge interne de USB HID.

FICHIERS
~/.ssh/id_ecdsa
~/.ssh/id_ecdsa_sk
~/.ssh/id_ed25519
~/.ssh/id_ed25519_sk
~/.ssh/id_rsa
    Ces fichiers contiennent l’identité d’authentification ECDSA, ECDSA hébergée par un authentificateur, Ed25519, Ed25519 hébergée par un authentificateur ou RSA de l’utilisateur.

Les fichiers d'identité ne doivent être accessibles en lecture que pour l'utilisateur. Notez que ssh-add ignorera tout fichier d'identité s'il est accessible pour les autres.

CODE DE RETOUR
Le code de retour est 0 en cas de réussite, 1 si la commande spécifiée échoue et 2 si ssh-add ne parvient pas à contacter l'agent d'authentification.

VOIR AUSSI
ssh(1), ssh-agent(1), ssh-askpass(1), ssh-keygen(1), sshd(8)

AUTEURS
OpenSSH est un dérivé 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 corrigé de nombreux bogues, rajouté de nouvelles fonctionnalités et créé OpenSSH. Markus Friedl a contribué à la prise en charge des versions 1.5 et 2.0 du protocole SSH.

TRADUCTION
La traduction française de cette page de manuel a été créée par Lucien Gentis <lucien.gentis@waika9.com>

Cette traduction est une documentation libre ; veuillez vous reporter à 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 RESPONSABILITÉ LÉGALE.

Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à debian-l10n-french@lists.debian.org.