NOM

ssh-copy-id — Utiliser des clés valables localement pour autoriser les connexions à un hôte distant

SYNOPSIS

DESCRIPTION

ssh-copy-id est un script qui utilise ssh(1) pour se connecter à un hôte distant (probablement en utilisant un mot de passe de connexion ; l'authentification par mot de passe doit donc être activée, sauf si on utilise de manière intelligente les identités multiples). Ce script rassemble une liste d’une ou plusieurs empreintes (comme décrit ci-après) et tente de se connecter en utilisant chaque clé pour voir si l’une d’entre elles n’est pas déjà installée (bien entendu, si vous n’utilisez pas ssh-agent(1), cette action peut aboutir à ce que vous soyez sollicité pour des phrases secrètes de manière répétitive). Il rassemble ensuite une liste des clés avec lesquelles la connexion a échoué et, en utilisant ssh(1), active la connexion avec ces clés sur le serveur distant. Par défaut, il ajoute les clés en les enregistrant à la fin du fichier ~/.ssh/authorized_keys de l’utilisateur distant (en créant le fichier et le répertoire, si nécessaire). Il peut aussi détecter si le système distant est un matériel de type « NetScreen », et utiliser sa commande « set ssh pka-dsa clé ... » à la place.

Les options sont les suivantes :

-i [fichier_identité]

N’utiliser que la/les clé(s) contenues dans fichier_identités (au lieu de rechercher des identités à l’aide de ssh-add(1) ou dans le fichier_ID_par_défaut). Si fichier_identités ne se termine pas par l’extension .pub, cette dernière est ajoutée. Si fichier_identités est omis, c’est le fichier_ID_par_défaut qui sera utilisé.

Notez que cette option permet de s’assurer que les clés copiées possèdent le commentaire souhaité et/ou que des options supplémentaires sont appliquées en assurant que le fichier de clés possède ces définitions en tant que préférences avant de tenter la copie.

-f

Mode forcé : ne pas vérifier si les clés sont présentes sur le serveur distant. Cela implique que cette option n’a pas besoin de la clé privée. Bien entendu, la spécification de cette option peut provoquer des copies multiples de la même clé sur le système distant.

-n

Cette option permet de simuler une exécution. La/les clé(s) qui auraient dû être installées sont simplement affichées au lieu d’être effectivement installées sur le système distant.

-s

Mode SFTP : en général, les clés publiques sont installées en exécutant des commandes sur le serveur distant. Avec cette option le fichier ~/.ssh/authorized_keys de l’utilisateur sera téléchargé, modifié localement puis téléversé à l’aide de sftp. Cette option s’avère utile si le serveur possède des restrictions quant aux commandes qui peuvent y être exécutées.

-t chemin_cible

Cette option permet de spécifier le chemin vers lequel les clés doivent être ajoutées sur le système cible (par défaut « .ssh/authorized_keys »).

-p port

Cette option spécifie le port auquel se connecter sur l'hôte distant.

-F ssh_config, -o option_ssh

Ces options sont simplement transmises telles quelles à ssh/sftp, avec leurs arguments, permettant à l’utilisateur de définir un autre fichier de configuration ou d'autres options, respectivement.

Plutôt que de spécifier ces options sur la ligne de commande, il est souvent préférable d’utiliser les définitions (hôte par hôte) dans le fichier de configuration de ssh(1)  : ssh_config(5).

-x

Cette option permet de déboguer le script ssh-copy-id lui-même. Elle définit l’option « -x » de l’interpréteur de commande de sorte que vous puissiez voir l’exécution des commandes.

-h, -?

Afficher un résumé du mode d’emploi.

Sans l’option -i, le comportement par défaut consiste à vérifier si « ssh-add -L » affiche quelque chose, et dans l’affirmative, ce sont ces clés qui seront utilisées. Notez que dans ce cas, le commentaire de la clé sera le nom de fichier qui a été donné à ssh-add(1) lorsque la clé a été chargée dans votre ssh-agent(1) au lieu du commentaire contenu dans ce fichier, ce qui est un peu dommage. Dans le cas contraire, si ssh-add(1) n’affiche aucune clé, c’est le contenu du fichier_ID_par_défaut qui sera utilisé.

Le fichier_ID_par_défaut est le fichier le plus récent qui correspond à ~/.ssh/id*.pub (à l’exclusion de ceux qui correspondent à ~/.ssh/*-cert.pub)  ; par conséquent, si vous créez une clé qui ne correspond pas à celle que vous voulez voir utilisée par ssh-copy-id, exécutez simplement la commande touch(1) avec le fichier .pub de votre clé préférée pour redéfinir ce dernier comme le plus récent.

EXEMPLES

Si vous avez déjà installé des clés d’un système sur de nombreux hôtes distants et si vous créez une nouvelle clé sur une nouvelle machine cliente, il peut être difficile de garder en mémoire la liste des systèmes sur lesquels vous avez installé la nouvelle clé. Une solution à ce problème consiste à charger la nouvelle et la/les ancienne(s) clé(s) dans votre ssh-agent(1). Chargez tout d’abord la nouvelle clé sans l’option -c, puis chargez une ou plusieurs anciennes clés dans l’agent, éventuellement en se connectant à l’aide de ssh à la machine cliente qui possède cette ancienne clé, à l’aide de l’option -A pour autoriser la redirection d’agent :

Maintenant, si la nouvelle clé est installée sur le serveur, vous serez autorisé à vous connecter sans confirmation, alors que si seulement la/les ancienne(s) clé(s) sont activées, une confirmation vous sera demandée, ce qui indiquera que vous devez vous déconnecter et exécuter

Dans ce cas, vous pouvez utiliser l’option -i pour vous assurer que le commentaire de la clé installée est bien celui du fichier .pub, au lieu du simple nom de fichier qui a été chargé dans votre agent. Cette option permet aussi de s’assurer que seule l’identité que vous souhaitez sera installée, et non toutes les clés que contient votre ssh-agent(1). Bien entendu, vous pouvez spécifier une autre identité ou utiliser le contenu de l’agent ssh-agent(1), si vous le souhaitez.

Nous avons mentionné l’option -c de ssh-add(1)  : vous pouvez l’indiquer quand vous utilisez la redirection d’agent pour éviter que votre clé ne soit interceptée, mais il est préférable d’utiliser la commande ProxyCommand et l’option -W de ssh(1) pour rebondir à travers les serveurs distants tout en effectuant toujours une authentification directe d’un bout à l’autre. De cette manière, les différents rebonds intermédiaires n’ont pas accès à votre ssh-agent(1). Une recherche sur le Web pour « ssh proxycommand nc » devrait vous en apporter la preuve flagrante (notez que l’approche moderne consiste à utiliser l’option -W au lieu de nc(1)).

VOIR AUSSI

ssh(1), ssh-agent(1), sshd(8)

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