NOM

ssh-agent — Agent d’authentification d’OpenSSH

SYNOPSIS

DESCRIPTION

ssh-agent est un programme permettant de conserver les clés privées utilisées pour l’authentification par clé publique. L’agent peut être localisé et automatiquement utilisé pour l’authentification en utilisant des variables d’environnement lors de la connexion à d’autres machines en utilisant ssh(1).

Les options sont les suivantes :

-a socket_liaison

Lier l’agent au socket de domaine Unix socket_liaison. La valeur par défaut est $TMPDIR/ssh-XXXXXXXXXX/agent.<ppid>.

-c

Générer des commandes C-shell sur la sortie standard. Il s’agit du comportement par défaut si la variable d’environnement SHELL laisse supposer qu’il s’agit d’un interpréteur de commande de style csh.

-D

Mode avant-plan. Lorsque cette option est spécifiée, ssh-agent n’effectue pas de bifurcation à l’aide de « fork ».

-d

Mode débogage. Lorsque cette option est spécifiée, ssh-agent n’effectue pas de bifurcation à l’aide de « fork » et affiche les informations de débogage sur la sortie d’erreur 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 ».

-k

Tuer l'agent actuel (identifié par la variable d'environnement SSH_AGENT_PID).

-O option

Spécifier une option au démarrage de ssh-agent. Les options prises en charge sont : allow-remote-pkcs11, no-restrict-websafe et websafe-allow.

L’option allow-remote-pkcs11 permet aux clients d’un ssh-agent redirigé de charger des bibliothèques de fournisseur PKCS#11 ou FIDO. Par défaut, seuls les clients locaux peuvent effectuer cette opération. Notez que signaler qu’un client de ssh-agent distant est effectué par ssh(1) et qu’utiliser d’autres outils pour rediriger l’accès au socket de l’agent permet de contourner cette restriction.

L’option no-restrict-websafe demande à ssh-agent d’autoriser les signatures qui utilisent des clés FIDO qui peuvent être des requêtes d’authentification web. Par défaut, ssh-agent refuse les demandes de signature pour des clés FIDO où la chaîne de clé d’application ne commence pas par « ssh: » et lorsque les données à signer ne semblent pas être une demande d’authentification utilisateur ssh(1) ou une signature ssh-keygen(1). Le comportement par défaut consiste à empêcher un accès redirigé vers une clé FIDO de rediriger aussi implicitement la capacité à s’authentifier auprès de sites web.

Sinon, l'option websafe-allow permet de spécifier une liste de motifs de chaînes d’application de clés pour remplacer la liste d'autorisations d'application par défaut, par exemple : “websafe-allow=ssh:*,example.org,*.example.com”

Voir la section MOTIFS de ssh_config(5) pour une description de la syntaxe des listes de motifs.

-P fournisseurs_autorisés

Spécifier une liste sous forme de motifs de chemins acceptables de bibliothèques partagées d’intergiciel pour fournisseur PKCS#11 et authentificateur FIDO qui pourront être utilisées avec les options -S ou -s de ssh-add(1). Les bibliothèques qui ne correspondent pas à la liste de motifs spécifiée seront rejetées. La liste par défaut est « usr/lib*/*,/usr/local/lib*/* ».

Voir la section MOTIFS de ssh_config(5) pour une description de la syntaxe des listes de motifs.

-s

Générer des commandes Bourne shell sur la sortie standard. Il s’agit du comportement par défaut si la variable d’environnement SHELL laisse supposer qu’il ne s’agit pas d’un interpréteur de commande de style csh.

-t durée_de_vie

Cette option permet de définir la valeur par défaut de la durée de vie maximale des identités ajoutées à l'agent. La durée de vie peut être spécifiée en secondes ou dans un format spécifié dans sshd_config(5). Une durée de vie spécifiée pour une identité à l’aide de ssh-add(1) outrepasse cette valeur. Sans cette option, la durée de vie est illimitée.

commande [arg ...]

Si une ligne de commande est fournie (avec des arguments optionnels), elle est exécutée comme sous-processus de l'agent. L’agent quitte automatiquement lorsque la commande spécifiée a terminé son exécution.

Il y a trois méthodes principales pour démarrer un agent. La première consiste à démarrer l’agent au lancement d’une session X où tous les autres programmes ou fenêtres sont démarrés en tant qu’enfants du programme ssh-agent. L’agent exécute une commande pour laquelle ses variables d’environnement sont exportées, par exemple ssh-agent xterm &. Lorsque la commande se termine, l’agent en fait de même.

La seconde méthode est utilisée pour une session de connexion. Lorsque ssh-agent démarre, il affiche les commandes de l’interpréteur de commande nécessaires pour définir ses variables d’environnement, qui en retour peuvent être évaluées dans l’interpréteur de commande appelant, par exemple eval `ssh-agent -s`.

Dans ces deux cas, ssh(1) consulte ces variables d’environnement et les utilise pour établir une connexion avec l'agent.

La troisième manière d'exécuter ssh-agent consiste à activer un socket à partir d'un processus de supervision tel que systemd. Dans ce mode, le processus de supervision crée le socket d'écoute et est responsable du démarrage de .Nm selon les besoins, ainsi que de la communication de l'emplacement de l'écouteur de socket aux autres programmes de la session de l'utilisateur. L'activation de socket est utilisé quand ssh-agent est démarré avec l'un des indicateurs -d ou -D, qu'aucune adresse d'écoute de socket n'est spécifiée par l'indicateur -a et que les deux variables d'environnement LISTEN_FDS et LISTEN_PID sont correctement fournies par le processus de supervision.

Initialement, l’agent ne contient aucune clé privée. Les clés sont ajoutées à l’aide de ssh-add(1) ou par ssh(1) si l’option AddKeysToAgent est définie dans ssh_config(5). Il est possible de stocker simultanément plusieurs identités dans ssh-agent et ssh(1) les utilisera automatiquement si elles sont présentes. ssh-add(1) permet aussi de supprimer des clés de ssh-agent et de demander quelles sont les clés que contient ce dernier.

Pour éviter de stocker les données d’authentification sur d’autres machines, il est possible de rediriger les connexions avec ssh-agent depuis d’autres hôtes distants à l’aide de l’option -A de ssh(1) (lisez cependant les avertissements documentés dans ce dernier). Les phrases de passe et clés privées d’authentification ne sont jamais transmises sur le réseau : la connexion avec l’agent est redirigée à travers des connexions distantes SSH et le résultat est renvoyé au demandeur, ce qui permet aux utilisateurs d’accéder à leurs identités n’importe où sur le réseau de manière sécurisée.

ssh-agent supprimera toutes les clés qu'il a chargées à la réception de SIGUSR1.

ENVIRONNEMENT

SSH_AGENT_PID

Au démarrage de ssh-agent, ce dernier enregistre le nom de l’identifiant de processus de l’agent (PID) dans cette variable.

SSH_AUTH_SOCK

Au démarrage de ssh-agent, ce dernier crée un socket de domaine Unix et enregistre son nom de chemin dans cette variable. Elle n’est accessible que pour l’utilisateur actuel, mais elle peut être facilement modifiée par le superutilisateur ou une autre instance du même utilisateur.

Dans Debian, ssh-agent est installé avec le bit set-group-id défini afin d’empêcher les attaques ptrace(2) de retrouver les clés privées. Cela a pour effet de bord la suppression par l’éditeur de liens à l’exécution de certaines variables d’environnement comme LD_PRELOAD, LD_LIBRARY_PATH, et TMPDIR, ce qui peut avoir des implications en matière de sécurité pour les programmes set-id. Si vous devez définir une de ces variables d’environnement, vous devrez le faire dans le programme exécuté par ssh-agent.

FICHIERS

$TMPDIR/ssh-XXXXXXXXXX/agent.<ppid>

Sockets de domaine Unix utilisés pour la connexion avec l'agent d'authentification. Ces sockets ne doivent être accessibles en lecture que pour leur propriétaire. Ils sont automatiquement supprimés lorsque l’exécution de l'agent se termine.

VOIR AUSSI

ssh(1), ssh-add(1), ssh-keygen(1), ssh_config(5), sshd(8)

AUTEURS

OpenSSH est dérivé de la version originale et libre de ssh 1.2.12 par Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt et Dug Song ont supprimé de nombreux bogues, rajouté des fonctionnalités plus récentes et ont 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 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