Remarque importante :la machine que vous appelez "machine locale" n'a aucune importance. La vraie histoire commence lorsque vous êtes déjà sur 100.100.100.1 . Dans le cadre de scp et dans le contexte de cette réponse "local" est la machine où scp est invoqué par vous.
Pourquoi la première [commande] échoue-t-elle ?
Vous avez essayé de copier entre deux hôtes (officiellement) distants. scp reconnaît [email protected]:/path/1/ en tant que chemin non local. Peu importe [email protected] pointe vers la machine locale. L'outil ne vérifie pas (et ne devrait pas) vérifier si une adresse qui semble distante pointe vers la machine locale. Juste en faisant référence à la source comme si elle était distante, vous avez fait scp traitez-le comme distant. De plus, la destination était éloignée.
La copie entre deux hôtes distants peut se faire avec ou sans le -3 choix :
-3
Les copies entre deux hôtes distants sont transférées via l'hôte local. Sans cette option, les données sont copiées directement entre les deux hôtes distants. […]
Le fragment en gras s'applique à votre cas (même si votre scp ne prend pas en charge -3 ).
Si vous utilisez -v avec votre première commande
scp -v -i ~/keyfile -r [email protected]:/path/1/ [email protected]:/path/2/
vous verrez scp se connecte de l'hôte local à l'hôte source ("accessoirement" étant le même hôte) en utilisant la clé spécifiée avec -i . (Apparemment, l'hôte est configuré pour accepter cette clé, probablement parce que l'autre serveur utilise une clé identique pour se connecter.)
Ensuite, vous verrez un autre scp est appelé sur l'hôte source. La commande est :
scp -v -r /path/1/ [email protected]:/path/2/
-v et -r sont là parce qu'ils étaient dans votre commandement local. Le chemin source est traduit en chemin local ; la destination est inchangée. Si cette commande s'exécute avec succès, les données seront "copiées directement entre les deux hôtes distants".
Notez qu'il n'y a pas de -i . Devrait -i ~/keyfile Soyez là? Ou plutôt -i /home/cindy/keyfile ou alors? (parce que le scp local obtenu quelque chose comme ça après que le shell local a développé le tilde).
Non. En général, un hôte source distant peut être (et est généralement) différent de l'hôte local. Un chemin valide pour l'hôte local peut pointer vers n'importe quoi ou rien sur l'hôte distant. Si scp sur l'hôte source a été invoqué avec -i , cela causerait plus de problèmes qu'il n'en résoudrait. C'est une bonne chose -i ne se propage pas à la commande invoquée sur l'hôte source. Mais ensuite, l'hôte se connecte à la destination en utilisant sa clé par défaut ou tout ce que sa configuration lui dit d'utiliser.
Dans votre cas, il semble qu'il faille le ~/keyfile local pour se connecter à l'hôte de destination. L'hôte source détient le bon fichier (car dans ce cas particulier, le local et la source sont la même machine), mais le scp la commande qui se connecte réellement à la destination manque de -i (comme il se doit en général) et donc la clé n'est pas utilisée.
Votre deuxième commande utilisait un chemin local comme source, seule la destination était distante. Dans ce cas, la clé spécifiée avec -i a été utilisé pour se connecter de l'hôte local à l'hôte de destination, exactement comme vous l'aviez prévu. Par conséquent, cela a fonctionné.
Notez si vous avez configuré la machine locale pour utiliser automatiquement ~/keyfile pour se connecter à l'autre serveur (IdentityFile en ~/.ssh/config ), alors la première commande fonctionnerait. L'hôte local se connecterait inutilement à lui-même, seulement pour se dire de se connecter à la destination, mais cela fonctionnerait toujours. La première connexion utiliserait ~/keyfile à cause de -i , la deuxième connexion utiliserait ~/keyfile à cause de la configuration.
Dans le manuel scp, description de l'option -3 :les copies entre deux hôtes distants sont transférées via l'hôte local. Sans cette option, les données sont copiées directement entre les deux hôtes distants. Notez que cette option désactive la jauge de progression et sélectionne le mode batch pour le deuxième hôte, car scp ne peut pas demander de mots de passe ou de phrases secrètes pour les deux hôtes.
Selon la description, le premier échoue car 2 serveurs distants communiqueront directement (en vrai, le serveur 100.100.100.1 communiquera avec le serveur 100.100.100.2 via ssh) donc vous avez les options :
- Utilisez l'option -3.
- Configurez 2 serveurs distants pour pouvoir s'authentifier avec la clé ssh du fichier de clés. Si vous pouvez vous connecter du serveur 100.100.100.1 au serveur 100.100.100.2 avec la clé ssh, votre commande d'origine fonctionnera.