Ottieni file dal server a due passi [chiuso]


14

Abbiamo la seguente situazione:

  1. La mia macchina
  2. Una macchina gateway
  3. La macchina target

Non ho i diritti di root su entrambi # 2 e # 3. Inoltre, non posso davvero archiviare informazioni (non più di 200 MiB) sulla macchina n. 2 (poiché si tratta di essere un gateway per il resto della rete, non più di quello). Sulla macchina n. 3 c'è una cartella, di circa 3 GiB, che voglio copiare in locale. Non posso SSH da # 1 a # 3, ma posso SSH a # 2 e quindi a # 3. Inoltre, non è possibile impostare una coppia di chiavi pubblica privata tra # 2 e # 3, ma esiste una coppia di chiavi installata tra # 1 e # 2.

Normalmente uso la combinazione di SSH e tar per farlo:

ssh name@host "tar cf - folder" > folder.tar

Ma in questo caso ciò richiederebbe una sorta di nidificazione e non riesco a farlo.

Quindi, quale sarebbe un buon modo per ottenere i dati dal n. 3 al n. 1?

Risposte:


27

È possibile creare un tunnel SSH tramite machine2, quindi in un'altra sessione connettersi al tunnel.

Ad esempio, aprire due sessioni della CLI su machine1. Nella prima sessione eseguire quanto segue:

MACHINE1$ ssh -L 2022:MACHINE3:22 <user>@MACHINE2

Nella seconda sessione eseguire quanto segue:

MACHINE1 $ ssh -p 2022 <user>@localhost

Quello che sta succedendo con il primo comando è che una porta locale (2022 su machine1) viene tunnelata sulla porta 22 su machine3 usando la tua connessione SSH a machine2.

Con il secondo comando ti connetti alla porta locale appena aperta (2022) ed è come se ti stessi collegando direttamente a machine3.

Ora, se si desidera utilizzare il tipico processo di trasferimento dei file, è possibile effettuare le seguenti operazioni:

ssh -p 2022 <user>@localhost "tar cf - /path/to/remote/directory/" > filename.tar

In alternativa, puoi familiarizzare con rsync e fare qualcosa del genere invece:

rsync -aHSv --progress -e 'ssh -p 2022' <user>@localhost:/path/to/remote/directory/ /path/to/local/directory/

Supponendo che l'obiettivo finale non è ottenere un tarball.


2
L'uso ProxyCommande ssh -Wi due sshcomandi possono essere combinati in un'unica riga di comando. Se hai una versione molto recente del client OpenSSH, c'è un argomento che ti permetterà di fare tutto con un solo sshcomando.
Kasperd,

+1 per rsync;)
NieDzejkob,

Uso tar perché il trasferimento di molti file richiede più tempo del trasferimento di un file di grandi dimensioni. Rsync risolve questo?
Cheiron,

Quando si eseguono trasferimenti remoti rsync esegue il checksum dei dati in transito (all'estremità di ricezione, prima che li scriva sul disco), quindi ci vorrà più tempo per trasferire un file. Tuttavia, è tempo ben speso.
Gene,

5

È inoltre possibile utilizzare la funzionalità di sessione master delle versioni più recenti di SSH. È descritto qui:

https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Multiplexing

Probabilmente tutto ciò di cui hai bisogno è modificare / creare il tuo .ssh / config. Aggiungi le definizioni che controllano le sessioni Master:

ControlMaster auto
ControlPath ~/.ssh/cm_socket/%r@%h:%p
ControlPersist 4h
ServerAliveInterval 30

Quindi è possibile specificare la definizione del primo server hop come:

Host first_hop
Hostname <your first host FQDN or IP>
User <your user>

E il secondo hop utilizzerà il tuo primo server hop come proxy:

Host second_hop
Hostname <your second host FQDN or IP>
User <your user>
ProxyCommand ssh -W %h:%p first_hop

Non dimenticare di creare la directory ~ / .ssh / cm_socket e le autorizzazioni di configurazione dovrebbero essere 644.

Quindi dovresti essere in grado di SSH o SCP direttamente da / verso il tuo secondo server. Possono esserci più server concatenati in questo modo.


3
Dalla lettura del tuo link, non penso che ControlMastersia necessario il multiplexing / per il proxy. La pagina più pertinente in quel wikibook è questa: en.wikibooks.org/wiki/OpenSSH/Cookbook/Proxies_and_Jump_Hosts
IMSoP

Si, sono d'accordo. Ci sono molti modi. Comunque considero la sessione del Master la più elegante. Si tratta solo di preferenze personali ;-)
Jaroslav Kucera,

Uno o l'altro di noi aveva frainteso qualcosa. Per quanto posso vedere, la "connessione principale" riguarda l'uso efficiente delle risorse di rete e non ha nulla a che fare con la domanda. Non è un modo diverso di farlo, è solo irrilevante per il compito da svolgere.
IMSoP,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.