Solution 1 :
De loin, le moyen le plus simple consiste simplement à le copier via scp. De plus, cette syntaxe fonctionne réellement contrairement à certaines des autres suggestions.
Vous ne pouvez pas battre cette syntaxe pour plus de facilité. Il vous permet de copier, rsynchroniser ou tout ce que vous voulez de manière récursive sans avoir à prendre en compte des tuyaux potentiellement complexes. Cette syntaxe est intuitivement claire, sera plus facilement supportable par les Sys Admins qui vous suivent et ne fait pas un usage inutile de cat.
scp -3 devappserver:/path/to/copy/from qaappserver:/path/to/copy/to
À partir de la page de manuel scp :-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.
Dans l'exemple ci-dessous
- Votre poste de travail s'appelle MacBook-Pro.
- Dev Jump Box s'appelle devjumpserver
- Dev Application Server est nommé devapplicationserver
- Est sur la zone DNS LAN nommée .local
- QA Jump Box s'appelle qajumpserver
- QA Application Server est nommé qaapplicationserver
- Est sur la zone LAN DNZ nommée .local
- Nous allons effectuer une copie test d'un fichier /etc/hosts de 670 Go ;-)
- On suppose que vous avez configuré l'authentification par clé publique SSH.
Voici un fichier ~/.ssh/config qui met en place l'accès direct depuis votre poste de travail aux serveurs d'application via le saut approprié (alias serveur bastion).
MacBook-Pro:~ barrychapman$ cat ~/.ssh/config Host * ServerAliveInterval 60 Host devapplicationsever HostName devapplicationserver.local ProxyCommand ssh -i ~/.ssh/id_rsa [email protected] -W %h:%p User barrychapman Host qaapplicationserver HostName qaapplicationserver.local ProxyCommand ssh -i ~/.ssh/id_rsa [email protected] -W %h:%p User barrychapman MacBook-Pro:~ barrychapman$
Test de présence du fichier sur le serveur cible, il n'y sera pas.
MacBook-Pro:~ barrychapman$ ssh qaapplicationserver ls /tmp/hosts ls: cannot access /tmp/hosts: No such file or directory Killed by signal 1. MacBook-Pro:~ barrychapman$
Copions maintenant un fichier du serveur Dev Application vers l'application QA via votre poste de travail.
MacBook-Pro:~ barrychapman$ scp -3 devapplicationserver:/etc/hosts qaapplicationserver:/tmp/ Killed by signal 1. Killed by signal 1. MacBook-Pro:~ barrychapman$
Vérifions maintenant la présence du fichier copié sur le QA Application Server. Ce sera là cette fois.
MacBook-Pro:~ barrychapman$ ssh qaapplicationserver ls /tmp/hosts /tmp/hosts Killed by signal 1. MacBook-Pro:~ barrychapman$
Remarque
Lors de la fermeture d'une connexion ProxyCommand, vous verrez le message d'avertissement "Tué par le signal 1". C'est SSH qui détruit la connexion ProxyCommand et il n'y a pas lieu de s'alarmer. Vous pouvez vous en débarrasser en ajoutant LogLevel Quiet à la strophe de configuration de votre hôte bastion.
Solution 2 :
TUYAUX !
Si Internet est une série de tubes, Unix est une série de tubes -- quelque chose comme :
cat ginormous-file | ssh [email protected] "cat | ssh [email protected] \"cat >out\" "
devrait fonctionner.
Si vous devez traverser plus d'hôtes, ajoutez plus de canaux (et plus de couches imbriquées de \ -citation échappée) selon les besoins. (Notez cependant que si le pipeline/l'échappement devient si complexe que vous devez dessiner un diagramme ou recourir à compter sur vos doigts pour déterminer combien de fois vous devez doubler les échappements, il est probablement temps d'admettre la défaite et de mettre en place un VPN approprié !)