SSH-COPY-ID(1) General Commands Manual SSH-COPY-ID(1) NOM ssh-copy-id - Utiliser des cles valables localement pour autoriser les connexions a un hote distant SYNOPSIS ssh-copy-id [-f] [-n] [-s] [-x] [-i [fichier_identites]] [-t chemin_cible] [-F ssh_config] [[-o option_ssh] ...] [-p port] [utilisateur@]nom_hote ssh-copy-id -h | -? DESCRIPTION ssh-copy-id est un script qui utilise ssh(1) pour se connecter a un hote distant (probablement en utilisant un mot de passe de connexion ; l'authentification par mot de passe doit donc etre activee, sauf si on utilise de maniere intelligente les identites multiples). Ce script rassemble une liste d'une ou plusieurs empreintes (comme decrit ci-apres) et tente de se connecter en utilisant chaque cle pour voir si l'une d'entre elles n'est pas deja installee (bien entendu, si vous n'utilisez pas ssh-agent(1), cette action peut aboutir a ce que vous soyez sollicite pour des phrases secretes de maniere repetitive). Il rassemble ensuite une liste des cles avec lesquelles la connexion a echoue et, en utilisant ssh(1), active la connexion avec ces cles sur le serveur distant. Par defaut, il ajoute les cles en les enregistrant a la fin du fichier ~/.ssh/authorized_keys de l'utilisateur distant (en creant le fichier et le repertoire, si necessaire). Il peut aussi detecter si le systeme distant est un materiel de type << NetScreen >>, et utiliser sa commande << set ssh pka-dsa cle ... >> a la place. Les options sont les suivantes : -i [fichier_identite] N'utiliser que la/les cle(s) contenues dans fichier_identites (au lieu de rechercher des identites a l'aide de ssh-add(1) ou dans le fichier_ID_par_defaut). Si fichier_identites ne se termine pas par l'extension .pub, cette derniere est ajoutee. Si fichier_identites est omis, c'est le fichier_ID_par_defaut qui sera utilise. Notez que cette option permet de s'assurer que les cles copiees possedent le commentaire souhaite et/ou que des options supplementaires sont appliquees en assurant que le fichier de cles possede ces definitions en tant que preferences avant de tenter la copie. -f Mode force : ne pas verifier si les cles sont presentes sur le serveur distant. Cela implique que cette option n'a pas besoin de la cle privee. Bien entendu, la specification de cette option peut provoquer des copies multiples de la meme cle sur le systeme distant. -n Cette option permet de simuler une execution. La/les cle(s) qui auraient du etre installees sont simplement affichees au lieu d'etre effectivement installees sur le systeme distant. -s Mode SFTP : en general, les cles publiques sont installees en executant des commandes sur le serveur distant. Avec cette option le fichier ~/.ssh/authorized_keys de l'utilisateur sera telecharge, modifie localement puis televerse a l'aide de sftp. Cette option s'avere utile si le serveur possede des restrictions quant aux commandes qui peuvent y etre executees. -t chemin_cible Cette option permet de specifier le chemin vers lequel les cles doivent etre ajoutees sur le systeme cible (par defaut << .ssh/authorized_keys >>). -p port Cette option specifie le port auquel se connecter sur l'hote distant. -F ssh_config, -o option_ssh Ces options sont simplement transmises telles quelles a ssh/sftp, avec leurs arguments, permettant a l'utilisateur de definir un autre fichier de configuration ou d'autres options, respectivement. Plutot que de specifier ces options sur la ligne de commande, il est souvent preferable d'utiliser les definitions (hote par hote) dans le fichier de configuration de ssh(1) : ssh_config(5). -x Cette option permet de deboguer le script ssh-copy-id lui-meme. Elle definit l'option << -x >> de l'interpreteur de commande de sorte que vous puissiez voir l'execution des commandes. -h, -? Afficher un resume du mode d'emploi. Sans l'option -i, le comportement par defaut consiste a verifier si << ssh-add -L >> affiche quelque chose, et dans l'affirmative, ce sont ces cles qui seront utilisees. Notez que dans ce cas, le commentaire de la cle sera le nom de fichier qui a ete donne a ssh-add(1) lorsque la cle a ete chargee 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 cle, c'est le contenu du fichier_ID_par_defaut qui sera utilise. Le fichier_ID_par_defaut est le fichier le plus recent qui correspond a ~/.ssh/id*.pub (a l'exclusion de ceux qui correspondent a ~/.ssh/*-cert.pub) ; par consequent, si vous creez une cle qui ne correspond pas a celle que vous voulez voir utilisee par ssh-copy-id, executez simplement la commande touch(1) avec le fichier .pub de votre cle preferee pour redefinir ce dernier comme le plus recent. EXEMPLES Si vous avez deja installe des cles d'un systeme sur de nombreux hotes distants et si vous creez une nouvelle cle sur une nouvelle machine cliente, il peut etre difficile de garder en memoire la liste des systemes sur lesquels vous avez installe la nouvelle cle. Une solution a ce probleme consiste a charger la nouvelle et la/les ancienne(s) cle(s) dans votre ssh-agent(1). Chargez tout d'abord la nouvelle cle sans l'option -c, puis chargez une ou plusieurs anciennes cles dans l'agent, eventuellement en se connectant a l'aide de ssh a la machine cliente qui possede cette ancienne cle, a l'aide de l'option -A pour autoriser la redirection d'agent : utilisateur@nouveau_client$ ssh-add utilisateur@nouveau_client$ ssh -A ancien_client utilisateur@ancien_client$ ssh-add -c Non ... demande de phrase secrete ... utilisateur@ancien_client$ logoff utilisateur@nouveau_client$ ssh un_serveur Maintenant, si la nouvelle cle est installee sur le serveur, vous serez autorise a vous connecter sans confirmation, alors que si seulement la/les ancienne(s) cle(s) sont activees, une confirmation vous sera demandee, ce qui indiquera que vous devez vous deconnecter et executer utilisateur@nouveau_client$ ssh-copy-id -i un_serveur Dans ce cas, vous pouvez utiliser l'option -i pour vous assurer que le commentaire de la cle installee est bien celui du fichier .pub, au lieu du simple nom de fichier qui a ete charge dans votre agent. Cette option permet aussi de s'assurer que seule l'identite que vous souhaitez sera installee, et non toutes les cles que contient votre ssh-agent(1). Bien entendu, vous pouvez specifier une autre identite ou utiliser le contenu de l'agent ssh-agent(1), si vous le souhaitez. Nous avons mentionne l'option -c de ssh-add(1) : vous pouvez l'indiquer quand vous utilisez la redirection d'agent pour eviter que votre cle ne soit interceptee, mais il est preferable d'utiliser la commande ProxyCommand et l'option -W de ssh(1) pour rebondir a travers les serveurs distants tout en effectuant toujours une authentification directe d'un bout a l'autre. De cette maniere, les differents rebonds intermediaires n'ont pas acces a 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 a utiliser l'option -W au lieu de nc(1)). VOIR AUSSI ssh(1), ssh-agent(1), sshd(8) 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.12.107+deb13-amd64 $Mdocdate: 17 juin 2010 $ Linux 6.12.107+deb13-amd64