Nota importante:la macchina che chiami "macchina locale" è totalmente irrilevante. La vera storia inizia quando sei già su 100.100.100.1 . Nel contesto di scp e nel contesto di questa risposta "locale" è la macchina dove scp viene richiamato da te.
Perché il primo [comando] fallisce?
Hai provato a copiare tra due host (formalmente) remoti. scp riconosce [email protected]:/path/1/ come percorso non locale. Non importa [email protected] punta alla macchina locale. Lo strumento non controlla (e non dovrebbe) controllare se un indirizzo che sembra remoto punta al computer locale. Solo facendo riferimento alla fonte come se fosse remota, hai fatto scp trattalo come remoto. Anche la destinazione era remota.
La copia tra due host remoti può essere eseguita con o senza -3 opzione:
-3
Le copie tra due host remoti vengono trasferite tramite l'host locale. Senza questa opzione i dati vengono copiati direttamente tra i due host remoti. […]
Il frammento in grassetto si applica al tuo caso (anche se il tuo scp non supporta -3 ).
Se usi -v con il tuo primo comando
scp -v -i ~/keyfile -r [email protected]:/path/1/ [email protected]:/path/2/
vedrai scp si connette dall'host locale all'host di origine ("incidentalmente" è lo stesso host) utilizzando la chiave specificata con -i . (Apparentemente l'host è configurato per accettare questa chiave, probabilmente perché l'altro server utilizza una chiave identica per connettersi.)
Quindi vedrai un altro scp viene richiamato sull'host di origine. Il comando è:
scp -v -r /path/1/ [email protected]:/path/2/
-v e -r sono lì perché erano nel tuo comando locale. Il percorso di origine viene tradotto in un percorso locale; la destinazione è invariata. Se questo comando viene eseguito correttamente, i dati verranno "copiati direttamente tra i due host remoti".
Nota che non c'è -i . Dovrebbe -i ~/keyfile esserci? O meglio -i /home/cindy/keyfile o così? (perché il scp locale ottenuto qualcosa del genere dopo che la shell locale ha espanso la tilde).
No. In generale, un host di origine remoto può essere (e di solito è) diverso dall'host locale. Un percorso valido per l'host locale può puntare a qualcosa oa niente sull'host remoto. Se scp sull'host di origine è stato richiamato con -i , causerebbe più problemi di quanti ne potrebbe risolvere. È una buona cosa -i non si propaga al comando richiamato sull'host di origine. Ma poi l'host si connette alla destinazione usando la sua chiave predefinita o qualunque cosa la sua configurazione gli dica di usare.
Nel tuo caso sembra che sia necessario il ~/keyfile locale per connettersi all'host di destinazione. L'host di origine contiene il file giusto (perché in questo caso particolare il locale e l'origine sono la stessa macchina), ma il scp il comando che effettivamente si connette alla destinazione manca di -i (come dovrebbe in generale) e quindi la chiave non viene utilizzata.
Il tuo secondo comando utilizzava un percorso locale come origine, solo la destinazione era remota. In questo caso la chiave specificata con -i è stato utilizzato per connettersi dall'host locale all'host di destinazione, esattamente come pianificato. Quindi ha funzionato.
Nota se hai configurato la macchina locale per utilizzare automaticamente ~/keyfile per connettersi all'altro server (IdentityFile in ~/.ssh/config ), quindi il primo comando funzionerebbe. L'host locale si connetterebbe inutilmente a se stesso, solo per dire a se stesso di connettersi alla destinazione, ma funzionerebbe comunque. La prima connessione userebbe ~/keyfile a causa di -i , la seconda connessione utilizzerà ~/keyfile a causa della configurazione.
Dal manuale scp, descrizione dell'opzione -3:le copie tra due host remoti vengono trasferite tramite l'host locale. Senza questa opzione i dati vengono copiati direttamente tra i due host remoti. Tieni presente che questa opzione disabilita l'indicatore di avanzamento e seleziona la modalità batch per il secondo host, poiché scp non può richiedere password o passphrase per entrambi gli host.
Secondo la descrizione prima fallisce perché 2 server remoti comunicheranno direttamente (in realtà il server 100.100.100.1 comunicherà con il server 100.100.100.2 tramite ssh) quindi devi opzioni:
- Usa l'opzione -3.
- Configura 2 server remoti per essere in grado di autenticarsi con la chiave ssh del file di chiavi. Se riesci ad accedere dal server 100.100.100.1 al server 100.100.100.2 con la chiave ssh, il tuo comando originale funzionerà.