Copie datos a través del túnel SSH en varios saltos

14

Tenemos dos entornos principales en cuestión:

Desarrollo y QA

Cada entorno tiene dos servidores:

  • Jump Box
  • Servidor de aplicaciones

Para conectarse al servidor de aplicaciones, primero debe conectarse al cuadro de salto, y luego SSH al servidor de aplicaciones.

Hay algunas reglas establecidas por cortesía del firewall:

  • DEBE conectarse al servidor de aplicaciones a través de la caja de salto
  • El servidor de aplicaciones no puede conectarse a ninguno de los cuadros de salto
  • Los cuadros de salto están en la misma subred y PUEDEN hablar entre ellos.

Nuestro problema

Tenemos mucho contenido (670 GB) en el DEVELOPMENT APPLICATION SERVER, y necesitamos llevar esto al QA APPLICATION SERVER.

Copiar estos datos en los cuadros de salto no es una opción porque carecen de la cantidad de espacio requerida.

Investigué un poco y aprendí que potencialmente podríamos hacer una serie de túneles a través de estos servidores para poder transmitir los datos directamente de un servidor de aplicaciones a otro a través de los túneles. Sin embargo, el problema es que no podemos conectarnos a la caja de salto desde el servidor de aplicaciones.

¿Tenemos alguna opción? Esto se está convirtiendo en una situación desesperada, y el tiempo es esencial. No tenemos tiempo para descargar los datos y volver a cargarlos. La copia a través de la red en los servidores se realizará rápidamente, ya que es una conexión gigabit.

linux ssh ssh-tunnel tunnel Barry Chapman
fuente
2
Una vez establecida la conexión, puede copiar de cualquier manera: $ devel_host $ tar -cf - | ssh -t jumbox 'ssh app_serv "tar -xf -"' o al revés tar.
Alex_www
para que podamos conectarnos desde dev jump box al servidor de aplicaciones de desarrollo, pero no al revés. Si tenemos esa conexión establecida, ¿podemos copiar de cualquier manera? ¿Cuál es la mejor manera de mover este contenido al otro servidor de aplicaciones sin guardarlo primero en los cuadros de salto?
Barry Chapman
Exactamente, "tubería" "alquitrán" es una solución más simple.
Alex_www

Respuestas:

15

Con mucho, la forma más fácil es simplemente copiarlo a través de scp. Además, esta sintaxis en realidad funciona a diferencia de algunas de las otras sugerencias.

No se puede superar esta sintaxis por facilidad. Le permite copiar recursivamente, rsync o lo que quiera sin la molestia de considerar tuberías potencialmente complejas. Esta sintaxis es intuitivamente clara, será más fácilmente compatible con los administradores del sistema que lo siguen y no hace un uso inútil del gato .

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

Desde la página de manual de scp : las -3copias entre dos hosts remotos se transfieren a través del host local. Sin esta opción, los datos se copian directamente entre los dos hosts remotos. Tenga en cuenta que esta opción deshabilita el medidor de progreso.

En el siguiente ejemplo

  • Su estación de trabajo se llama MacBook-Pro.
  • Dev Jump Box se llama devjumpserver
  • Dev Application Server se llama devapplicationserver
    • Está en la zona DNS de LAN llamada .local
  • QA Jump Box se llama qajumpserver
  • QA Application Server se llama qaapplicationserver
    • Está en la zona LAN DNZ llamada .local
  • Realizaremos una copia de prueba de un archivo de 670GB / etc / hosts ;-)
  • Se supone que tiene configurada la autenticación de clave pública SSH.



Aquí hay un archivo ~ / .ssh / config que configura el acceso directo desde su estación de trabajo a los servidores de aplicaciones a través del salto apropiado (también conocido como servidor de bastión).

MacBook-Pro: ~ barrychapman $ cat ~ / .ssh / config
Anfitrión *
  ServerAliveInterval 60
Servidor de desvalorización
  HostName devapplicationserver.local
  ProxyCommand ssh -i ~ / .ssh / id_rsa [email protected] -W% ​​h:% p
  Usuario barrychapman
Host qaapplicationserver
  HostName qaapplicationserver.local
  ProxyCommand ssh -i ~ / .ssh / id_rsa [email protected] -W% ​​h:% p
  Usuario barrychapman

MacBook-Pro: ~ barrychapman $



Al probar la presencia del archivo en el servidor de destino, no estará allí.

MacBook-Pro: ~ barrychapman $ ssh qaapplicationserver ls / tmp / hosts
ls: no se puede acceder / tmp / hosts: no existe tal archivo o directorio
Asesinado por la señal 1.
MacBook-Pro: ~ barrychapman $



Ahora copiemos un archivo del servidor de aplicaciones Dev a la aplicación QA a través de su estación de trabajo.

MacBook-Pro: ~ barrychapman $ scp -3 devapplicationserver: / etc / hosts qaapplicationserver: / tmp /
Asesinado por la señal 1.
Asesinado por la señal 1.
MacBook-Pro: ~ barrychapman $



Ahora verifiquemos la presencia del archivo copiado en el QA Application Server. Estará allí esta vez.

MacBook-Pro: ~ barrychapman $ ssh qaapplicationserver ls / tmp / hosts
/ tmp / hosts
Asesinado por la señal 1.
MacBook-Pro: ~ barrychapman $

Nota

Al cerrar una conexión de ProxyCommand, verá el mensaje de advertencia "Eliminado por la señal 1". Esto es SSH derribando la conexión ProxyCommand y no es motivo de alarma. Puede deshacerse de él agregando LogLevel Quieta su stanza de configuración de host de bastión.

appx
fuente
Saludos, esto resolvió nuestro problema. ¡Feliz Navidad!
Barry Chapman
¿Qué quieres decir con "stanza de configuración de host de bastión"? @BraveNewCurrency?
Andrew Wolfe
Considero que cada línea "Host" y las configuraciones debajo de ella son una estrofa (como en poesía). Si agrega "LogLevel Quiet" debajo de la línea "Host" de su bastión, solo se aplicará a ese host.
BraveNewCurrency
8

¡TUBERÍA!

Si Internet es una serie de tubos , Unix es una serie de tubos, algo así como:

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

Deberia trabajar.

Si necesita atravesar más hosts, agregue más tuberías (y más capas anidadas de \citas con escape) según sea necesario. (Sin embargo, tenga en cuenta que si la tubería / escape se vuelve tan compleja que tiene que dibujar un diagrama o recurrir a contar con los dedos para determinar cuántas veces tiene que duplicar los escapes , probablemente sea hora de admitir la derrota y configurar una VPN adecuada !)

voretaq7
fuente
1
Como Alex_www señaló en su comentario, si no necesita el archivo intermedio para nada, también puede canalizar la salida de taralrededor. (También en usted no necesita el caten las etapas intermedias de la tubería - sshes feliz de comer la entrada estándar y retransmitirla El. catSólo me hace sentir mejor y es un marcador para otros comandos útiles es posible que desee usar, al igual que tee.)
voretaq7
Creo que el problema de la OP es que no hay máquina que tanto tiene los datos y puede hacer las conexiones, ni hay una máquina que puede ver todo y todo el mundo (para actuar como conector para todas las tuberías).
MadHatter
1
@MadHatter Si ese fuera el caso, una combinación de nuestras dos respuestas funcionaría (conéctese al servidor de desarrollo, reenvíe un puerto al puerto SSH del servidor de salto, luego ejecute la tubería SSH sobre ese puerto). Esto, por supuesto, hace que la solución sea cada vez más desagradable hasta el punto de que las personas comenzarán a protestar fuera de su oficina con grandes letreros que dicen VPN! NOW!en ellas ...
voretaq7
Porque?, si. Sí lo harían ¡Ojalá!
MadHatter
¿Hacer esto significa que el servidor intermedio (en este caso user@host1) tendrá en algún momento el cat ginormous-filealmacenamiento completo en cualquier momento? ¿O solo se envían los datos directamente user@host2? ¿O de alguna manera se transmite? ¿Cómo es tarrelevante para esto? Supongo que es relevante para la penúltima pregunta que hice. Ninguna de estas preguntas es retórica por cierto ...
hello_there_andy
1

Si entiendo correctamente, tiene dos servidores de salto (jump-qa y jump-dev) que protegen dos servidores de aplicaciones (app-qa y app-dev); los servidores de salto pueden ssh entre sí; ninguna otra casilla que el servidor de salto relevante puede enviar ssh al servidor de aplicaciones correspondiente. Los servidores de aplicaciones pueden enviar ssh a nadie. Se debe transferir un archivo de app-dev a app-qa. Ambos servidores de salto carecen del espacio para una copia provisional de los datos.

Puede resolver esto con el túnel ssh. Configuramos una conexión a un servidor de aplicaciones remoto, llevando un túnel remoto que se conecta de nuevo a un puerto no utilizado en su servidor de salto. Configuramos una segunda conexión de un servidor de salto al otro servidor de salto, llevando un túnel que recoge el extremo colgante del puerto reenviado remotamente desde el túnel uno y lo envía al puerto ssh del otro servidor de aplicaciones.

Configure los túneles (cada uno de estos comandos deberá ejecutarse en una ventana separada jump-qa):

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

Ahora debería encontrar que en app-qa, puede hacer telnet localhost 2345y obtener el banner ssh de app-dev. Luego puede copiar el archivo de datos:

app-qa% scp -P 2345 localhost:/path/on/app-dev/data.dat data.dat
MadHatter
fuente
Hay dos cajas de salto: una frente al servidor de aplicaciones de control de calidad y otra frente al servidor de aplicaciones DEV. Las cajas de salto pueden comunicarse entre sí
Barry Chapman
¿El cliente tiene espacio para una copia provisional?
MadHatter
No, no hay suficiente espacio
Barry Chapman
cuando dices cliente, ¿a qué servidor te refieres?
Barry Chapman
Yo había entendido mal. Mi comprensión actual es que no hay cliente; Hay dos servidores de salto y dos servidores de aplicaciones.
MadHatter