Mam jeden duży plik na serwerze onei chcę go skopiować na serwer twoprzy użyciu scp. Mam poprawnie skonfigurowane klucze i mogę ssh / scp do obu serwerów z mojego pulpitu.

Plik, który muszę skopiować, jest większy niż wolne miejsce na dysku twardym mojej stacji roboczej, więc chciałem zrobić:

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

ale mam:

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

Nie mamy tutaj DNS (nie pytaj mnie dlaczego), więc mam to w mojej ~ / .ssh / config:

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

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

Jeśli spróbuję użyć mniejszego pliku i przenieść go z onemojej stacji roboczej, a następnie do two, to działa dobrze:

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

Korzystając z adresów IP bezpośrednio, jak sugerowano w komentarzu, otrzymałem:

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

To nie problem:

Rozmiar nie jest tutaj problemem - był tylko „wyzwalaczem” tego problemu, ponieważ nie było sposobu, aby zapisać bigfile.tar.gzna mojej stacji roboczej. Problem występuje niezależnie od rozmiaru pliku.

Pytanie:

Dlaczego polecenie:

scp oneremote:file secondremote:file

zgłasza błąd niezależnie od tego, czy używasz .ssh/configaliasów, czy bezpośrednio adresów IP?

Rozwiązany - w pewnym sensie - wciąż szukający wyjaśnień - podzieliłem duży plik na mniejsze pliki i przesyłałem je jeden po drugim przez moją stację roboczą. Nadal zastanawiam się, dlaczego to nie zadziałało. Wciąż byłbym wdzięczny za wyjaśnienie, co było nie tak ...

Znalazłem przyczynę niepowodzenia: Wygląda na to, że byłem głupi. Myślałem , że to polecenie

scp one:file two:file

tworzył dwa połączenia z każdym serwerem, a następnie odbierał dane z jednego i natychmiast wysyłał je do dwóch, a tym samym działał jak przekaźnik.

Oczywiście tak nie jest, ponieważ prosta -vopcja ujawniła, że ​​w rzeczywistości łączy się tylko z jednym, a z jednego próbuje połączyć się z dwoma . Co oczywiście nie jest możliwe, ponieważ serwer pierwszy nie powinien łączyć się z dwoma .

Prosta rura

Spróbuj tego:

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

Pierwszy powinien wysłać zawartość pliku na twój komputer, podczas gdy drugi powinien wysłać go na drugi komputer. Obliczę sumę kontrolną na obu końcach po transferze, aby upewnić się, że nic nie zostanie zgubione lub zniekształcone po drodze.

Opracuj tunele

W przypadku bardziej skomplikowanych aplikacji można użyć tuneli ssh. Na przykład możesz spróbować czegoś takiego:

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

Następnie możesz otworzyć połączenie onez localhostportem maszyny 5001, które zostanie przekierowane dwukrotnie i zakończy się połączeniem twoz localhostportem 22. To jest port ssh, więc możesz użyć go do kolejnego scp, rsync lub cokolwiek innego. Możesz także uruchomić rsyncserwer twoi przekierować port 873 zamiast 22. Lub możesz użyć ncobu stron do przesłania surowych danych, używając dowolnego numeru portu.

Główną korzyścią między powyższym podejściem jest to, że masz dwukierunkowe połączenie Tcp między dwiema maszynami, a nie tylko jednokierunkową rurę. W ten sposób obie strony mogą wymieniać informacje, co jest szczególnie ważne w rsyncsprawie.

Pełny kredyt za tę odpowiedź trafia na /superuser//a/602436/142948

Potrzebujesz -3opcji dla scp:

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

-3: Kopie między dwoma hostami zdalnymi są przesyłane przez hosta lokalnego. Bez tej opcji dane są kopiowane bezpośrednio między dwoma zdalnymi hostami.

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

W przeciwnym razie drugi alias „dwa” jest rozpoznawany na hoście „jeden” , co może nie istnieć.

Ponieważ masz dostęp użytkownika do serwera źródłowego (jednego), dlaczego nie zalogować się i uruchomić polecenie scp bezpośrednio na tym serwerze ... Jeśli obawiasz się, że potrwa to zbyt długo, uruchom polecenie wewnątrz a screennastępnie odłącz od ekranu za pomocą Ctrl+a di niech biegnie.

Jeśli jednak musisz to zrobić ze stacji roboczej, a klucze SSH ze źródła do serwera docelowego działają OK, wyślij scppolecenie jako parametr sshpolecenia, na przykład:

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

Wyszukiwanie komunikatu o błędzie: „Weryfikacja klucza hosta nie powiodła się”. wydaje się być najprostszą rzeczą do zrobienia tutaj. Znalazłem te pytania i odpowiedzi na askubuntu zatytułowane: Problem z połączeniem SSH z błędem „Weryfikacja klucza hosta nie powiodła się…” .

Jedna z odpowiedzi na te pytania i sugestie sugerowała, że ​​problem dotyczył sprzecznego wpisu w twoim ~/.ssh/known_hostspliku. Możesz usunąć kłopotliwe wpisy z tego pliku za pomocą dowolnego edytora tekstu lub użyć tego polecenia, aby usunąć wpisy:

$ ssh-keygen -R hostname

Gdzie hostnamebyłby adres IP lub nazwa serwera, z którego próbujesz się połączyć. Nawiasem mówiąc, wszystkie powyższe byłyby na hoście drugim .