Ho un grosso file sul server onee voglio copiarlo sul server twousando scp. Ho le chiavi configurate correttamente e posso inviare ssh / scp su entrambi i server dal mio desktop.

Il file che devo copiare è più grande dello spazio libero sul disco fisso della mia workstation, quindi volevo fare:

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

ma ho ottenuto:

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

Non abbiamo DNS qui (non chiedermi perché), quindi ho questo nel mio ~ / .ssh / config:

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

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

Se provo con un file più piccolo e lo trasferisco dalla onemia workstation e poi a two, funziona benissimo:

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

Quando ho usato gli indirizzi IP direttamente come suggerito nel commento, ho ottenuto:

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

Non un problema:

La dimensione non è un problema qui - era solo un "trigger" per questo problema in quanto non c'era modo di archiviare bigfile.tar.gzsulla mia workstation. Il problema si verifica indipendentemente dalle dimensioni del file.

Domanda:

Perché il comando:

scp oneremote:file secondremote:file

genera un errore a prescindere se si utilizzano gli .ssh/configalias o si utilizzano direttamente gli indirizzi IP?

Risolto - in un certo senso - ancora alla ricerca di spiegazioni - Ho diviso il bigfile in file più piccoli e li ho trasferiti uno per uno attraverso la mia workstation. Mi chiedo ancora perché non ha funzionato. Quindi apprezzerei ancora qualche spiegazione di ciò che era sbagliato ..

Ho trovato una ragione per cui fallisce: sembra che stia diventando sciocco. Ho pensato che il comando

scp one:file two:file

stava creando due connessioni per ciascun server e quindi riceveva i dati da uno e li inviava immediatamente a due e si comportava quindi come un relay.

Questo chiaramente non è il caso, perché una semplice -vopzione ha rivelato che in realtà si collega solo a uno e da uno tenta di connettersi a due . Il che ovviamente non è possibile perché il server uno non dovrebbe connettersi a due .

Pipa semplice

Prova questo:

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

Il primo dovrebbe inviare il contenuto del file al tuo computer, mentre il secondo dovrebbe inviarlo al secondo computer. Calcolerei un checksum ad entrambe le estremità dopo il trasferimento, per assicurarmi che nulla si sia perso o confuso lungo il percorso.

Tunnel elaborati

Per applicazioni più elaborate, è possibile utilizzare tunnel ssh. Ad esempio, potresti provare qualcosa del genere:

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

Poi si può aprire una connessione su oneper la macchina localhostport 5001e sarà inoltrato due volte e finire come una connessione su twoal localhostporto 22. Questa è la porta ssh, quindi puoi usarla per l'ennesimo scp, per rsync o altro. È inoltre possibile avviare un rsyncserver twoe inoltrare la porta 873 anziché 22. In alternativa, è possibile utilizzare ncsu entrambi i lati per trasferire dati non elaborati, utilizzando un numero di porta arbitrario.

Il vantaggio principale tra l'approccio sopra è che si ha una connessione tcp bidirezionale tra le due macchine, anziché solo un tubo unidirezionale. In questo modo, le due parti possono scambiarsi informazioni, il che è particolarmente importante nel rsynccaso.

Il credito completo per questa risposta va a /superuser//a/602436/142948

È necessaria l' -3opzione per scp:

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

-3: Le copie tra due host remoti vengono trasferite attraverso l'host locale. Senza questa opzione i dati vengono copiati direttamente tra i due host remoti.

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

In caso contrario, il secondo alias "due" viene risolto sull'host "uno" , che potrebbe non esistere.

Dato che hai accesso utente al server di origine (uno), perché non accedere ed eseguire il comando scp su quel server direttamente ... Se temi che impiegherà troppo tempo, avvia il comando all'interno di un e screenpoi staccalo dallo schermo con Ctrl+a de lascialo correre.

Tuttavia, se è necessario eseguire questa operazione dalla workstation e le chiavi SSH dall'origine al server di destinazione funzionano correttamente, inviare il scpcomando come parametro di un sshcomando, ad esempio:

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

Ricerca del messaggio di errore: "Verifica chiave host non riuscita." sembrerebbe essere la cosa più semplice da fare qui. Ho trovato queste domande e risposte su askubuntu dal titolo: Problema di connessione SSH con errore "Verifica chiave host non riuscita ..." .

Una delle risposte a queste domande e risposte ha suggerito che il problema risiedeva in una voce in conflitto nel ~/.ssh/known_hostsfile. Puoi eliminare le voci problematiche da quel file usando qualsiasi editor di testo oppure puoi usare questo comando per rimuovere le voci:

$ ssh-keygen -R hostname

Dove hostnamesi trova l'indirizzo IP o il nome del server da cui si sta tentando di connettersi. A proposito, tutto quanto sopra sarebbe sull'host due .