scp zwischen zwei Servern, die sich nicht im selben Netzwerk befinden

Es gibt zwei Server, auf die ich mit 2 verschiedenen VPN-Verbindungen zugreifen kann. Ich habe es geschafft, dass beide VPNs gleichzeitig auf meinem Computer funktionieren (ein paar Routing-Regeln).

Ich möchte einen scp <remote1>:some/file <remote2>:destination/foldervon meinem Laptop-Terminal machen. Aber wenn ich dies versuchen, das scpKommando, der auf aufgerufen wird remote1 nicht finden kann remote2 , weil sie nicht im selben Netzwerk befindet. Kann scpich den Befehl erzwingen, dass er als Router über meinen Laptop geleitet wird?

Wenn ich es mit Nautilus versuche (Verbindung zum Server, beide Server, dann Kopieren-Einfügen), funktioniert es, aber ich möchte es von einem Terminal aus tun.

— Danduk82
quelle

Es ist Ihre Maschine, die sowohl remote1 als auch remote2 kontaktiert . Sind Sie sicher, dass remote1 nicht auf remote2 zugreifen kann ?

— Jan

Ja, der Fehler lautet ssh: Hostname <remote2> konnte nicht aufgelöst werden: Name oder Dienst nicht bekannt Verbindung verloren

— Danduk82

Und wenn ich versuche, die IP-Adresse direkt für <remote2> zu verwenden, schlägt die Verbindung nach einer Weile fehl (Hangout).

— Danduk82

Dann ist es wohl Ihr Computer, der keine Verbindung zu remote2 herstellen kann . Vielleicht sind die VPN - Verbindung unterbrochen wird oder ist flakey ...

— Jan

Nein, es funktioniert, auch der DNS funktioniert. Ich habe wirklich das Gefühl, dass der Befehl scp versucht, die Verbindung zwischen remote1 und remote2 direkt auf remote1 auszuführen .

— Danduk82

Antworten:

Neuere Versionen von scp haben die Option -3

-3

Copies between two remote hosts are transferred through the local host. Without this option the data is copied directly between the two remote hosts

— Andy
quelle

großartig! Genau das, was ich brauchte. Vielen Dank

— Danduk82

Toller Fund, das wusste ich nicht!

— Jan

Wenn Sie mehr Flexibilität benötigen als scp -3, machen Glatt- sshund Pfeifenbau Spaß.

Dies entspricht der Umleitung des Streams über den lokalen Computer:

ssh sourceRemote 'cat /path/to/sourceFile' \
| ssh destinationRemote 'cat > /path/to/destinationFile'

Sie können dann jederzeit weitere Stream-Umleitungen hinzufügen, um z. B. mehrere Zwischencomputer zu verketten, oder eine lokale Kopie der übertragenen Datei beim Weiterleiten speichern.

— Anko
quelle

Sie erhalten einen schönen Fortschrittsbalken, wenn der Quellcomputer pvinstalliert ist und Sie den ersten catdurch ihn ersetzen .

— Liori

Wenn Sie die Antwort von @ Anko erweitern, können Sie sie tarfür mehrere Dateien verwenden:

ssh -q user@sourcehost 'cd /source/path; tar -czf - files...' | \
ssh -q user@desthost 'cd /dest/path; tar -xzf -'

Die Komprimierung ist völlig optional - Ihre Daten sind möglicherweise nicht sehr komprimierbar oder groß genug, um den Overhead zu rechtfertigen. Wenn Ihre Version von tarnicht unterstützt -zSchaltern, Rohr durch gzip -cund gzip -dcjeweils.

PS: Beachten Sie, dass Versionen davon tarbeim Extrahieren keine führenden Schrägstriche entfernen (dh in absolute Pfadnamen schreiben, falls angegeben).

Bearbeiten: -e nonewird bei Pipes nicht benötigt, da kein Pseudo-Terminal zugewiesen ist.

— arielCo
quelle

sshverfügt über ein -CFlag zum Aktivieren der Stream-Komprimierung. Laut man-page wird derselbe Algorithmus verwendet, als gzipob. In der Handbuchseite wird auch die Verwendung erläutert: "Bei Modemleitungen und anderen langsamen Verbindungen ist eine Komprimierung wünschenswert, bei schnellen Netzwerken jedoch nur eine Verlangsamung."

— Anko

@Anko, das Problem bei der Verwendung -Chier ist, dass der lokale Computer die Daten dekomprimieren und erneut komprimieren muss. Wenn Sie sich tarfür die Komprimierung entscheiden, werden die komprimierten Daten ohne weitere Verarbeitung direkt durch die Pipe geleitet.

— cjm