Nota importante:La máquina que llamas "máquina local" es totalmente irrelevante. La verdadera historia comienza cuando ya estás en 100.100.100.1 . En el contexto de scp y en el contexto de esta respuesta, "local" es la máquina donde scp es invocado por usted.
¿Por qué falla el primer [comando]?
Intentó copiar entre dos (formalmente) hosts remotos. scp reconoce [email protected]:/path/1/ como una ruta no local. No importa [email protected] apunta a la máquina local. La herramienta no comprueba (y no debería comprobar) si una dirección que parece remota apunta a la máquina local. Con solo referirte a la fuente como si fuera remota, hiciste scp tratarlo como remoto. Además, el destino era remoto.
La copia entre dos hosts remotos se puede hacer con o sin el -3 opción:
-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. […]
El fragmento en negrita se aplica a su caso (incluso si su scp no es compatible con -3 ).
Si usa -v con tu primer comando
scp -v -i ~/keyfile -r [email protected]:/path/1/ [email protected]:/path/2/
verás scp se conecta desde el host local al host de origen ("por cierto" es el mismo host) usando la clave especificada con -i . (Aparentemente, el host está configurado para aceptar esta clave, probablemente porque el otro servidor usa una clave idéntica para conectarse).
Luego verá otro scp se invoca en el host de origen. El comando es:
scp -v -r /path/1/ [email protected]:/path/2/
-v y -r están allí porque estaban en su comando local. La ruta de origen se traduce a una ruta local; el destino no cambia. Si este comando se ejecuta correctamente, los datos se "copiarán directamente entre los dos hosts remotos".
Tenga en cuenta que no hay -i . Debería -i ~/keyfile estar allí? O más bien -i /home/cindy/keyfile ¿más o menos? (porque el scp local obtuvo algo como esto después de que el shell local expandiera la tilde).
No. En general, un host de origen remoto puede ser (y generalmente lo es) diferente del host local. Una ruta que sea válida para el host local puede apuntar a cualquier cosa o a nada en el host remoto. Si scp en el host de origen se invocó con -i , causaría más problemas de los que podría resolver. Es algo bueno -i no se propaga al comando invocado en el host de origen. Pero luego el host se conecta al destino usando su clave predeterminada o lo que sea que su configuración le diga que use.
En su caso, parece que uno necesita el ~/keyfile local para conectarse al host de destino. El host de origen contiene el archivo correcto (porque en este caso particular, el local y el origen son la misma máquina), pero el scp el comando que realmente se conecta al destino carece de -i (como debería ser en general) y por lo tanto la clave no se utiliza.
Su segundo comando usó una ruta local como fuente, solo el destino era remoto. En este caso la clave especificada con -i se usó para conectarse desde el host local al host de destino, exactamente como lo planeó. Por lo tanto, funcionó.
Tenga en cuenta si configuró la máquina local para usar automáticamente ~/keyfile para conectarse al otro servidor (IdentityFile en ~/.ssh/config ), entonces el primer comando funcionaría. El host local se conectaría innecesariamente a sí mismo, solo para decirse a sí mismo que se conecte al destino, pero aun así funcionaría. La primera conexión usaría ~/keyfile debido a -i , la segunda conexión usaría ~/keyfile debido a la configuración.
Del manual de scp, descripción de la opción -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. Tenga en cuenta que esta opción desactiva el medidor de progreso y selecciona el modo por lotes para el segundo host, ya que scp no puede solicitar contraseñas o frases de contraseña para ambos hosts.
De acuerdo con la descripción, primero falla porque 2 servidores remotos se comunicarán directamente (en realidad, el servidor 100.100.100.1 se comunicará con el servidor 100.100.100.2 a través de ssh), por lo tanto, tiene las opciones:
- Utilice la opción -3.
- Configure 2 servidores remotos para poder autenticarse con la clave ssh del archivo de claves. Si puede iniciar sesión desde el servidor 100.100.100.1 al 100.100.100.2 con la tecla ssh, su comando original funcionará.