Il s'agit de la commande ssh-copy-id qui peut être exécutée dans le fournisseur d'hébergement gratuit OnWorks en utilisant l'un de nos multiples postes de travail en ligne gratuits tels que Ubuntu Online, Fedora Online, l'émulateur en ligne Windows ou l'émulateur en ligne MAC OS
PROGRAMME:
Nom
ssh-copie-id — utiliser des clés disponibles localement pour autoriser les connexions sur une machine distante
SYNOPSIS
ssh-copie-id [-f] [-n] [-i [fichier_identité]] [-p port] [-o option_ssh] [utilisateur@]nom d'hôte
ssh-copie-id -h | -?
DESCRIPTION
ssh-copie-id est un script qui utilise ssh(1) pour se connecter à une machine distante (probablement à l'aide d'un
mot de passe de connexion, donc l'authentification par mot de passe doit être activée, à moins que vous n'ayez fait des
utilisation d'identités multiples). Il assemble une liste d'une ou plusieurs empreintes digitales (comme décrit
ci-dessous) et essaie de se connecter avec chaque clé, pour voir si l'une d'entre elles est déjà installée (de
bien sûr, si vous n'utilisez pas agent ssh(1) cela peut vous amener à être invité à plusieurs reprises
pour les phrases de passe). Il assemble ensuite une liste de ceux qui n'ont pas réussi à se connecter, et en utilisant ssh,
active les connexions avec ces clés sur le serveur distant. Par défaut, il ajoute les clés par
en les ajoutant à celui de l'utilisateur distant ~ / .ssh / clés_autorisées (création du fichier, et
répertoire, si nécessaire). Il est également capable de détecter si le système distant est un
NetScreen, et en utilisant sa commande "set ssh pka-dsa key ..." à la place.
Les options sont les suivantes :
-i fichier_identité
Utilisez uniquement la ou les clés contenues dans fichier_identité (plutôt que de chercher des identités
via ssh-add(1) ou dans le fichier_ID_par défaut). Si le nom du fichier ne se termine pas par .pub
ceci est ajouté. Si le nom de fichier est omis, le fichier_ID_par défaut est utilisé.
Notez que cela peut être utilisé pour s'assurer que les clés copiées ont le commentaire
préférences et/ou options supplémentaires appliquées, en veillant à ce que le fichier de clé les ait définies comme
préféré avant que la copie ne soit tentée.
-f Mode forcé : ne vérifie pas si les clés sont présentes sur le serveur distant. Ça signifie
qu'il n'a pas besoin de la clé privée. Bien sûr, cela peut entraîner plus d'un
copie de la clé en cours d'installation sur le système distant.
-n faire un essai à sec. Au lieu d'installer des clés sur le système distant, imprime simplement le
clé(s) qui auraient été installées.
-h, -? Imprimer le résumé de l'utilisation
-p port, -o option_ssh
Ces deux options sont simplement transmises sans modification, avec leur argument, pour
permettre à l'un de définir le port ou l'autre ssh(1) options, respectivement.
Plutôt que de les spécifier en tant qu'options de ligne de commande, il est souvent préférable d'utiliser
paramètres (par hôte) dans ssh(1) fichier de configuration : ssh_config (5).
Comportement par défaut sans -i, est de vérifier si 'ssh-add -L' fournit une sortie, et si c'est le cas
ces clés sont utilisées. Notez que cela se traduit par le commentaire sur la clé étant le nom de fichier
qui a été donné à ssh-add(1) lorsque la clé a été chargée dans votre agent ssh(1) plutôt que le
commentaire contenu dans ce fichier, ce qui est un peu dommage. Sinon, si ssh-add(1)
ne fournit aucun contenu de clé du fichier_ID_par défaut sera utilisé.
Votre fichier_ID_par défaut est le fichier le plus récent qui correspond à : ~/.ssh/id*.pub, (à l'exclusion de ceux
ce match ~ / .ssh /*-cert.pub) donc si vous créez une clé qui n'est pas celle que vous voulez
ssh-copie-id à utiliser, il suffit d'utiliser -nous(1) sur votre clé préférée .pub fichier pour le rétablir en tant que
la plus récente.
EXEMPLES
Si vous avez déjà installé les clés d'un système sur de nombreux hôtes distants et que vous
créer une nouvelle clé, sur une nouvelle machine client, par exemple, il peut être difficile de garder une trace de laquelle
systèmes sur lesquels vous avez installé la nouvelle clé. Une façon de gérer cela est de charger les deux
la nouvelle clé et l'ancienne clé(s) dans votre agent ssh(1). Chargez d'abord la nouvelle clé, sans le -c
option, puis chargez une ou plusieurs anciennes clés dans l'agent, éventuellement en ssh-ing au client
machine qui a cette ancienne clé, en utilisant le -A option pour autoriser le transfert de l'agent :
utilisateur@nouveauclient$ ssh-add
user@newclient$ ssh -Un ancien.client
utilisateur@oldl$ ssh-add -c
... invite pour la phrase de passe ...
user@old$ déconnexion
user@newclient$ ssh unserveur
maintenant, si la nouvelle clé est installée sur le serveur, vous serez autorisé à entrer sans invite, alors que si
vous n'avez activé que les anciennes clés, une confirmation vous sera demandée, ce qui vous indiquera
déconnectez-vous et exécutez
utilisateur@nouveau client$ ssh-copy-id -i un serveur
La raison pour laquelle vous voudrez peut-être spécifier l'option -i dans ce cas est de vous assurer que le
le commentaire sur la clé installée est celui du .pub fichier, plutôt que juste le nom du fichier
qui a été chargé dans votre agent. Il garantit également que seul l'identifiant que vous vouliez est installé,
plutôt que toutes les clés que vous avez dans votre agent ssh(1). Vous pouvez bien entendu préciser
un autre identifiant, ou utiliser le contenu du agent ssh(1) comme vous préférez.
Ayant mentionné ssh-add(1) -c option, vous pouvez envisager de l'utiliser chaque fois que vous utilisez l'agent
transfert pour éviter que votre clé ne soit détournée, mais il est préférable d'utiliser à la place ssh(1)
ProxyCommande et -W option, pour rebondir à travers des serveurs distants tout en faisant toujours une fin directe
authentification de bout en bout. De cette façon, le ou les tronçons intermédiaires n'ont pas accès à votre agent ssh(1). UNE
la recherche sur le Web de 'ssh proxycommand nc' devrait s'avérer instructive (NB l'approche moderne est
d'utiliser le -W option, plutôt que nc(1)).
Utiliser ssh-copy-id en ligne à l'aide des services onworks.net