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 :
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-agent1) 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-agent1 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-agent1, 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-agent1 redirigé.
Il est aussi important de noter que les restrictions de destination ne peuvent être appliquées par ssh-agent1 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).
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.
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.
Cette traduction est une documentation libre ; veuillez vous reporter à la Lk https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License version 3 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 à Mt debian-l10n-french@lists.debian.org Me .