scp z jednego zdalnego serwera na inny zdalny serwer

15

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 .

Jan Spurny
źródło
Czy próbowałeś po prostu zmienić polecenie scp, aby zamiast tego używać adresów IP, takich jak „scp jspurny @ ip_address_server_one: /opt/bigfile.tar.gz jspurny @ ip_address_server_two: /opt/bigfile.tar.gz”.
@tchester: Zrobiłem to teraz, ale daje tylko inny błąd (patrz zredagowane pytanie)
Jan Spurny
@ slm nie, nie mam problemów z rozmiarem.
Jan Spurny,
Gdy znalazłem wyjaśnienie błędów, chciałem dodać / zaakceptować je jako własną odpowiedź, ale wydaje mi się to trochę niesprawiedliwe, ponieważ tak naprawdę nie rozwiązuje problemu. Czy uważasz, że powinienem przeformułować pytanie na: Jak skopiować plik z serwera jeden na serwer drugi, używając mojej stacji roboczej jako przekaźnika? czy powinienem dodać wyjaśnienie mojej niemożności użycia opcji --verbose jako odpowiedź i zaakceptować ją?
Jan Spurny,

Odpowiedzi:

6

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.

MvG
źródło
1
Dzięki! To nie robi dokładnie tego, czego chciałem , ale tego, czego naprawdę potrzebowałem , co jest świetne.
Jan Spurny
16

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ć.

artfulrobot
źródło
Niestety, ta opcja wydaje się być dość nowa i rozpowszechniona na wszystkich dotychczasowych dystrybucjach.
whereswalden
2

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'
Marios Zindilis
źródło
Dzięki, to na pewno by działało, z tym wyjątkiem, że oba serwery wyłączyły PasswordAuthentication i nie mogę dodawać kluczy od jednego do drugiego - nie powinny być w stanie się ze sobą połączyć.
Jan Spurny,
0

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 .

slm
źródło
Nie jestem pewien, czy rozumiem. I można ssh onei twoserwerów z mojej stacji roboczej bez żadnych problemów .. zaczyna problem, gdy biegnę scp one:file two:fileze stacji roboczej. I nie ma known_hostspliku na jednym lub dwóch . Właśnie próbowałem usunąć klucze dla dwóch (nawet dla jednego ) na mojej stacji roboczej, ale nic się nie zmieniło (z wyjątkiem tego, czy jesteś pewien, że ty / n propt).
Jan Spurny,
@JanSpurny - Twoje odniesienie do stacji roboczej było nieco mylące w tym Q, przynajmniej dla mnie. Kiedy mówisz, że masz na myśli laptopa / komputer stacjonarny. Więc robisz coś takiego, kiedy mówisz, że to „działa”: scp workstation:file one:filei workstation:file two:file? Oczywiście nie musisz mówić „stacja robocza: plik”. Mówię to wprost ze względu na rozmowę.
slm
Mam na myśli to, że uruchomiłem wszystkie polecenia z mojej stacji roboczej. Więc było bardziej jak: workstation$ scp one:file filei workstation$ scp file two:file. W każdym razie myślę, że to rozwiązałem. Dodam to jako własną odpowiedź.
Jan Spurny,
@JSpSpny - OK, cieszę się, że to rozgryzłeś. Dzięki za pytanie BTW!
slm