Tengo un archivo grande en el servidor oney quiero copiarlo al servidor twousando scp. Tengo las claves configuradas correctamente y puedo enviar ssh / scp a ambos servidores desde mi escritorio.

El archivo que necesito copiar es más grande que el espacio libre en el disco duro de mi estación de trabajo, así que quería hacer:

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

pero tengo:

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

No tenemos DNS aquí (no me preguntes por qué), así que tengo esto en mi ~ / .ssh / config:

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

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

Si intento con un archivo más pequeño y lo transfiero onea mi estación de trabajo y luego a two, funciona bien:

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

Al usar direcciones IP directamente como se sugiere en el comentario, obtuve:

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

No es un problema:

El tamaño no es un problema aquí, solo fue un "desencadenante" de este problema, ya que no había forma de almacenarlo bigfile.tar.gzen mi estación de trabajo. El problema ocurre independientemente del tamaño del archivo.

Pregunta:

¿Por qué el comando:

scp oneremote:file secondremote:file

arroja un error independientemente de si usa .ssh/configalias o directamente usando direcciones IP?

Resuelto, más o menos, aún en busca de explicación , he dividido el archivo grande en archivos más pequeños y los transferí uno por uno a través de mi estación de trabajo. Todavía me pregunto por qué no funcionó. Así que aún agradecería alguna explicación de lo que estaba mal ...

Encontré una razón por la que falla: parece que estaba siendo tonto. Yo pensaba que el comando

scp one:file two:file

estaba creando dos conexiones a cada servidor y luego recibía datos de uno e inmediatamente los enviaba a dos y así actuaba como un relé.

Claramente, este no es el caso, porque una -vopción simple reveló que de hecho solo se conecta a uno y desde uno intenta conectarse a dos . Lo que obviamente no es posible porque se supone que el servidor uno no se conecta a dos .

Tubo simple

Prueba esto:

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

El primero debe enviar el contenido del archivo a su máquina, mientras que el segundo debe enviarlo a la segunda máquina. Calcularía una suma de verificación en ambos extremos después de la transferencia, para asegurarme de que nada se pierda o se confunda en el camino.

Elaborados túneles

Para aplicaciones más elaboradas, puede usar túneles ssh. Por ejemplo, podría intentar algo como esto:

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

Luego puede abrir una conexión oneal localhostpuerto de la máquina 5001y se reenviará dos veces y terminará como una conexión twoal localhostpuerto 22. Este es el puerto ssh, por lo que puede usarlo para otro scp, o para rsync, o lo que sea. También puede iniciar un rsyncservidor twoy reenviar el puerto 873 en lugar del 22. O puede usar ncambos lados para transferir datos sin procesar, utilizando un número de puerto arbitrario.

El principal beneficio entre el enfoque anterior es que tiene una conexión tcp bidireccional entre las dos máquinas, en lugar de una tubería unidireccional solamente. De esa manera, las dos partes pueden intercambiar información, lo cual es particularmente importante en el rsynccaso.

El crédito completo para esta respuesta va a /superuser//a/602436/142948

Necesitas la -3opción para scp:

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

-3: Las copias 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.

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

De lo contrario, el segundo alias "dos" se resuelve en el host "uno" , que puede no existir.

Puesto que usted tiene acceso del usuario al servidor de origen (uno) por qué no login y ejecutar el comando scp en ese servidor directamente ... Si le preocupa que se tardará demasiado tiempo, a continuación, iniciar el comando dentro de una screencontinuación, desprenderse de la pantalla con Ctrl+a dy déjalo correr.

Sin embargo, si debe hacer esto desde su estación de trabajo, y las claves SSH desde el servidor de origen al de destino funcionan bien, envíe el scpcomando como el parámetro de un sshcomando, como:

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

Buscando el mensaje de error: "Falló la verificación de la clave del host". parece ser lo más sencillo que hacer aquí. Encontré este Q&A en askubuntu titulado: Problema de conexión SSH con error "Error de verificación de clave de host ..." .

Una de las respuestas a esas preguntas y respuestas sugirió que el problema radicaba en una entrada en conflicto en su ~/.ssh/known_hostsarchivo. Puede eliminar las entradas problemáticas de ese archivo usando cualquier editor de texto o puede usar este comando para eliminar entradas:

$ ssh-keygen -R hostname

¿Dónde hostnameestaría la dirección IP o el nombre del servidor desde el que intenta conectarse? Todo lo anterior estaría en el host dos por cierto.