J'ai un gros fichier sur le serveur oneet je veux le copier sur le serveur en twoutilisant scp. J'ai les clés correctement configurées et je peux ssh / scp vers les deux serveurs depuis mon bureau.

Le fichier que je dois copier est plus grand que l'espace libre sur le disque dur de mon poste de travail, donc je voulais faire:

scp one:/opt/bigfile.tar.gz two:/opt/bigfile.tar.gz

mais j'ai:

ssh: Could not resolve hostname one: Name or service not known

Nous n'avons pas de DNS ici (ne me demandez pas pourquoi), donc je l'ai dans mon ~ / .ssh / config:

Host one
    Hostname        <IP address of server one>
    User            jspurny

Host two
    Hostname        <IP address of server two>
    User            jspurny

Si j'essaie avec un fichier plus petit et le transfère de oneà mon poste de travail puis à two, cela fonctionne très bien:

scp one:/opt/smallerfile.tar.gz .
scp smallerfile.tar.gz two:/opt/

Lors de l'utilisation des adresses IP directement comme suggéré dans le commentaire, j'ai obtenu:

$ scp jspurny@<one's IP>:bigfile.tar.gz jspurny@<two's ip>:bigfile.tar.gz
Host key verification failed.
lost connection

Pas une solution:

La taille n'est pas un problème ici - ce n'était qu'un «déclencheur» de ce problème car il n'y avait aucun moyen de stocker bigfile.tar.gzsur mon poste de travail. Le problème se produit quelle que soit la taille du fichier.

Question:

Pourquoi la commande:

scp oneremote:file secondremote:file

génère une erreur, peu importe si vous utilisez des .ssh/configalias ou utilisez directement des adresses IP?

Résolu - en quelque sorte - toujours à la recherche d'explications - j'ai divisé le gros fichier en fichiers plus petits et les ai transférés un par un via mon poste de travail. Je me demande toujours pourquoi cela n'a pas fonctionné. J'apprécierais donc encore quelques explications sur ce qui n'allait pas ..

Trouvé une raison pour laquelle il échoue: Il semble que j'étais stupide. Je pensais que la commande

scp one:file two:file

créait deux connexions à chaque serveur, puis recevait des données d' un et les envoyait immédiatement à deux et agissait ainsi comme un relais.

Ce n'est clairement pas le cas, car une simple -voption a révélé qu'il se connecte en fait à un seul et à partir d' un, il essaie de se connecter à deux . Ce qui n'est évidemment pas possible car le serveur un n'est pas censé se connecter à deux .

Pipe simple

Essaye ça:

ssh one 'cat file' | ssh two 'cat > file'

Le premier doit envoyer le contenu du fichier à votre machine, tandis que le second doit l'envoyer sur la deuxième machine. Je calculerais une somme de contrôle aux deux extrémités après le transfert, pour m'assurer que rien ne s'est perdu ou brouillé en cours de route.

Tunnels élaborés

Pour des applications plus élaborées, vous pouvez utiliser des tunnels ssh. Par exemple, vous pouvez essayer quelque chose comme ceci:

ssh -R 5001:127.0.0.1:5002 one
ssh -L 5002:127.0.0.1:22 two

Ensuite, vous pouvez ouvrir une connexion sur le port de la onemachine et elle sera transmise deux fois et se terminera en tant que connexion sur le port . Il s'agit du port ssh, vous pouvez donc l'utiliser pour encore un autre scp, ou pour rsync, ou autre. Vous pouvez également démarrer un serveur et transférer le port 873 au lieu de 22. Ou vous pouvez utiliser des deux côtés pour transférer des données brutes, en utilisant un numéro de port arbitraire.localhost5001twolocalhost22rsynctwonc

Le principal avantage entre l'approche ci-dessus est que vous disposez d'une connexion TCP bidirectionnelle entre les deux machines, au lieu d'un tuyau unidirectionnel uniquement. De cette façon, les deux parties peuvent échanger des informations, ce qui est particulièrement important dans le rsynccas.

Le crédit complet pour cette réponse va à /superuser//a/602436/142948

Vous avez besoin de l' -3option pour scp:

scp -3 one:/opt/bigfile.tar.gz two:/opt/bigfile.tar.gz

-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.

http://www.openbsd.org/cgi-bin/man.cgi?query=scp&sektion=1

Sinon, le deuxième alias «deux» est en cours de résolution sur l'hôte «un» , qui peut ne pas exister.

Puisque vous avez un accès utilisateur au serveur source (un), pourquoi ne pas vous connecter et exécuter votre commande scp directement sur ce serveur ... Si vous craignez que cela prenne trop de temps, démarrez la commande dans un screenpuis détachez-vous de l'écran avec Ctrl+a det laissez-le courir.

Cependant, si vous devez le faire à partir de votre poste de travail et que les clés SSH du serveur source au serveur de destination fonctionnent correctement, envoyez la scpcommande comme paramètre d'une sshcommande, comme:

ssh user@source 'scp /path/to/file user@destination:/path/to/file'

Recherche du message d'erreur: "La vérification de la clé d'hôte a échoué." semble être la chose la plus simple à faire ici. J'ai trouvé cette Q&R sur askubuntu intitulée: Problème de connexion SSH avec l'erreur «Échec de la vérification de la clé hôte…» .

L'une des réponses à cette Q&R a suggéré que le problème était lié à une entrée conflictuelle dans votre ~/.ssh/known_hostsfichier. Vous pouvez soit supprimer les entrées gênantes de ce fichier à l'aide de n'importe quel éditeur de texte, soit utiliser cette commande pour supprimer les entrées:

$ ssh-keygen -R hostname

Où hostnameserait l'adresse IP ou le nom du serveur à partir duquel vous essayez de vous connecter. Tout ce qui précède serait d'ailleurs sur l'hôte deux .