Nous avons deux principaux environnements en question:

Développement et assurance qualité

Chaque environnement possède deux serveurs:

• Boîte de saut
• Serveur d'application

Pour vous connecter au serveur d'applications, vous devez d'abord vous connecter au boîtier de connexion, puis SSH au serveur d'applications.

Il y a quelques règles en place grâce au pare-feu:

• Vous DEVEZ vous connecter au serveur d'applications via la boîte de saut
• Le serveur d'applications ne peut pas se connecter aux boîtes de saut
• Les boîtiers de connexion sont sur le même sous-réseau et PEUVENT se parler.

Notre problème

Nous avons beaucoup de contenu (670 Go) sur le DEVELOPMENT APPLICATION SERVER, et nous devons le faire parvenir au QA APPLICATION SERVER.

La copie de ces données dans les boîtes de saut n'est pas une option car elles manquent d'espace requis.

J'ai fait quelques recherches et j'ai appris que nous pourrions potentiellement faire une série de tunnels via ces serveurs afin que nous puissions diffuser les données directement d'un serveur d'application à l'autre via les tunnels. Cependant, le problème que nous ne pouvons pas nous connecter à la boîte de saut à partir du serveur d'applications.

Avons-nous des options? Cela devient une situation désespérée, et le temps presse. Nous n'avons pas le temps de télécharger les données et de les télécharger à nouveau. La copie sur le réseau sur les serveurs se fera rapidement, car il s'agit d'une connexion gigabit.

De loin, le moyen le plus simple est de simplement le copier via scp. De plus, cette syntaxe fonctionne en fait contrairement à certaines des autres suggestions.

Vous ne pouvez pas battre cette syntaxe pour plus de facilité. Il vous permet de copier, rsync récursivement ou tout ce que vous voulez sans avoir à considérer des canaux potentiellement complexes. Cette syntaxe est intuitivement claire, sera plus facilement supportable par les administrateurs Sys qui vous suivent et ne font pas usage inutile de cat .

scp -3 devappserver:/path/to/copy/from qaappserver:/path/to/copy/to

Depuis la page de manuel scp : les -3copies 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 le compteur de progression.

Dans l'exemple ci-dessous

• Votre poste de travail s'appelle MacBook-Pro.
• Dev Jump Box est nommé devjumpserver
• Dev Application Server est nommé devapplicationserver
  • Est sur la zone DNS LAN nommée .local
• QA Jump Box est nommé qajumpserver
• QA Application Server est nommé qaapplicationserver
  • Est sur la zone LAN DNZ nommée .local
• Nous allons effectuer une copie de test d'un fichier 670GB / etc / hosts ;-)
• Il est supposé que vous avez configuré l'authentification par clé publique SSH.

Voici un fichier ~ / .ssh / config qui configure l'accès direct de votre poste de travail aux serveurs d'applications via le saut approprié (aka bastion server).

MacBook-Pro: ~ barrychapman $  cat ~ / .ssh / config
Hôte *
  ServerAliveInterval 60
Host devapplicationsever
  Hostapp devapplicationserver.local
  ProxyCommand ssh -i ~ / .ssh / id_rsa barrychapman@devjumpserver.example.com -W% ​​h:% p
  User barrychapman
Host qaapplicationserver
  HostName qaapplicationserver.local
  ProxyCommand ssh -i ~ / .ssh / id_rsa barrychapman@qajumpserver.example.com -W% ​​h:% p
  User barrychapman

MacBook-Pro: ~ barrychapman $

Test de présence de fichier sur le serveur cible, il ne sera pas là.

MacBook-Pro: ~ barrychapman $ ssh qaapplicationserver ls / tmp / hosts
ls: impossible d'accéder à / tmp / hosts: aucun fichier ou répertoire de ce type
Tué par le signal 1.
MacBook-Pro: ~ barrychapman $

Copions maintenant un fichier du serveur d'application Dev vers l'application QA via votre poste de travail.

MacBook-Pro: ~ barrychapman $ scp -3 devapplicationserver: / etc / hosts qaapplicationserver: / tmp /
Tué par le signal 1.
Tué par le signal 1.
MacBook-Pro: ~ barrychapman $

Vérifions maintenant la présence du fichier copié sur le serveur d'application QA. Ce sera là cette fois.

MacBook-Pro: ~ barrychapman $ ssh qaapplicationserver ls / tmp / hosts
/ tmp / hosts
Tué par le signal 1.
MacBook-Pro: ~ barrychapman $ 

Remarque

Lors de la fermeture d'une connexion ProxyCommand, vous verrez le message d'avertissement "Killed by signal 1". Il s'agit de SSH interrompant la connexion ProxyCommand et il n'y a rien à craindre. Vous pouvez vous en débarrasser en ajoutant LogLevel Quietà votre strophe de configuration d'hôte bastion.

TUYAUX!

Si Internet est une série de tubes , Unix est une série de tuyaux - quelque chose comme:

cat ginormous-file | ssh user@host1 "cat | ssh user@host2 \"cat >out\" "

devrait marcher.

Si vous devez traverser plus d'hôtes, ajoutez plus de canaux (et plus de couches imbriquées de \citation avec échappement) selon les besoins. (Notez cependant que si le pipeline / é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 sur les évasions, il est probablement temps d'admettre la défaite et de configurer un VPN approprié !)

Si je comprends bien, vous avez deux serveurs de saut (jump-qa et jump-dev) protégeant deux serveurs d'application (app-qa et app-dev); les serveurs de saut peuvent ssh entre eux; aucune boîte autre que le serveur de saut correspondant ne peut ssh vers le serveur d'application correspondant. Les serveurs d'applications peuvent ssh à personne. Un fichier doit être transféré de app-dev vers app-qa. Les deux serveurs de saut manquent d'espace pour une copie provisoire des données.

Vous pouvez résoudre ce problème avec le tunneling ssh. Nous avons configuré une connexion à un serveur d'application distant, transportant un tunnel distant qui se connecte à nouveau à un port inutilisé sur son serveur de saut. Nous avons établi une deuxième connexion d'un serveur de saut à l'autre serveur de saut, transportant un tunnel qui récupère l'extrémité pendante du port transféré à distance depuis le tunnel un et l'envoie au port ssh de l'autre serveur d'applications.

Configurez les tunnels (chacune de ces commandes devra être exécutée dans une fenêtre distincte jump-qa):

jump-qa% ssh app-qa -R 2345:localhost:2346
jump-qa% ssh jump-dev -L 2346:app-dev:22

Vous devriez maintenant trouver que sur app-qa, vous pouvez faire telnet localhost 2345et obtenir la bannière ssh de app-dev. Vous pouvez ensuite copier le fichier de données:

app-qa% scp -P 2345 localhost:/path/on/app-dev/data.dat data.dat