Abbiamo due ambienti principali in questione:

Sviluppo e QA

Ogni ambiente ha due server:

• Jump Box
• Server delle applicazioni

Per connettersi al server delle applicazioni, è necessario prima connettersi al jump box e quindi SSH al server delle applicazioni.

Esistono alcune regole per gentile concessione del firewall:

• DEVI collegarti al server delle applicazioni tramite la jump box
• Il server delle applicazioni non può connettersi a nessuno dei jump box
• Le jump box si trovano sulla stessa sottorete e POSSONO parlare tra loro.

Il nostro problema

Abbiamo un sacco di contenuti (670 GB) sul DEVELOPMENT APPLICATION SERVER, e abbiamo bisogno di arrivare a questo QA APPLICATION SERVER.

La copia di questi dati nelle jump box non è un'opzione perché mancano della quantità richiesta di spazio.

Ho fatto alcune ricerche e ho appreso che potremmo potenzialmente fare una serie di tunnel attraverso questi server in modo da poter trasmettere i dati direttamente da un server di app all'altro tramite i tunnel. Tuttavia, il problema che non è possibile connettersi alla jump box dal server delle applicazioni.

Abbiamo qualche opzione? Sta diventando una situazione disperata e il tempo è essenziale. Non abbiamo tempo per scaricare i dati e ricaricarli. La copia attraverso la rete sui server andrà rapidamente, poiché si tratta di una connessione gigabit.

Di gran lunga il modo più semplice è semplicemente copiarlo via scp. Inoltre, questa sintassi funziona in realtà diversamente da altri suggerimenti.

Non puoi battere questa sintassi per facilità. Ti consente di copiare in modo ricorsivo, sincronizzare o qualsiasi cosa tu voglia senza la seccatura di considerare pipe potenzialmente complesse. Questa sintassi è intuitivamente chiara, sarà più facilmente supportata dagli amministratori di sistema che ti seguono e non fanno un uso inutile di cat .

scp -3 devappserver:/path/to/copy/from qaappserver:/path/to/copy/to

Dalla pagina man di scp : le -3copie tra due host remoti vengono trasferite attraverso l'host locale. Senza questa opzione i dati vengono copiati direttamente tra i due host remoti. Nota che questa opzione disabilita l'indicatore di avanzamento.

Nell'esempio seguente

• La tua workstation si chiama MacBook-Pro.
• Dev Jump Box si chiama devjumpserver
• Dev Application Server è chiamato devapplicationserver
  • Si trova nella zona DNS LAN denominata .local
• QA Jump Box si chiama qajumpserver
• QA Application Server si chiama qaapplicationserver
  • Si trova nella zona DNZ LAN denominata .local
• Eseguiremo una copia di prova di un file da 670 GB / etc / hosts ;-)
• Si presume che tu abbia configurato l'autenticazione con chiave pubblica SSH.

Ecco un file ~ / .ssh / config che configura l'accesso diretto dalla tua stazione di lavoro ai server delle applicazioni tramite il salto appropriato (ovvero il server bastione).

MacBook-Pro: ~ barrychapman $ cat ~ / .ssh / config
Ospite *
  ServerAliveInterval 60
Devapplications hosteverever
  Nome host devapplicationserver.local
  ProxyCommand ssh -i ~ / .ssh / id_rsa barrychapman@devjumpserver.example.com -W% ​​h:% p
  User barrychapman
Host qaapplicationserver
  Nome host qaapplicationserver.local
  ProxyCommand ssh -i ~ / .ssh / id_rsa barrychapman@qajumpserver.example.com -W% ​​h:% p
  User barrychapman

MacBook-Pro: ~ barrychapman $

Test per la presenza di file sul server di destinazione, non sarà lì.

MacBook-Pro: ~ barrychapman $ ssh qaapplicationserver ls / tmp / hosts
ls: impossibile accedere a / tmp / hosts: nessun file o directory
Ucciso dal segnale 1.
MacBook-Pro: ~ barrychapman $

Ora copiamo un file dal Dev Application Server all'applicazione QA tramite la tua workstation.

MacBook-Pro: ~ barrychapman $ scp -3 devapplicationserver: / etc / hosts qaapplicationserver: / tmp /
Ucciso dal segnale 1.
Ucciso dal segnale 1.
MacBook-Pro: ~ barrychapman $

Ora controlliamo la presenza del file copiato sul QA Application Server. Questa volta ci sarà.

MacBook-Pro: ~ barrychapman $ ssh qaapplicationserver ls / tmp / hosts
/ tmp / hosts
Ucciso dal segnale 1.
MacBook-Pro: ~ barrychapman $ 

Nota

Quando si chiude una connessione ProxyCommand, verrà visualizzato il messaggio di avviso "Ucciso dal segnale 1". Questo è SSH che abbatte la connessione ProxyCommand e non è nulla di cui allarmarsi. Puoi sbarazzartene aggiungendo LogLevel Quietalla tua stanza di configurazione dell'host del bastione.

TUBI!

Se Internet è una serie di tubi , Unix è una serie di tubi - qualcosa del tipo:

cat ginormous-file | ssh user@host1 "cat | ssh user@host2 \"cat >out\" "

dovrebbe funzionare.

Se è necessario attraversare più host, aggiungere più pipe (e più livelli nidificati di \citazione con escape) in base alle esigenze. (Nota comunque che se la pipeline / escape diventa così complessa che devi disegnare un diagramma o ricorrere al conteggio sulle dita per determinare quante volte devi raddoppiare sugli escape è probabilmente il momento di ammettere la sconfitta e impostare una VPN adeguata !)

Se ho capito bene, hai due server di salto (jump-qa e jump-dev) che proteggono due server di app (app-qa e app-dev); i server di salto possono ssh l'un l'altro; nessun box diverso dal relativo server di salto può essere inviato al corrispondente server delle app. I server delle app possono essere inviati a nessuno. Un file deve essere trasferito da app-dev ad app-qa. Entrambi i server jump mancano dello spazio per una copia provvisoria dei dati.

Puoi risolverlo con il tunneling ssh. Abbiamo impostato una connessione a un server di app remoto, trasportando un tunnel remoto che si ricollega a una porta inutilizzata sul suo server di salto. Abbiamo impostato una seconda connessione da un server di salto all'altro server di salto, portando un tunnel che raccoglie l'estremità penzolante della porta inoltrata in remoto dal tunnel uno e lo invia alla porta ssh dell'altro server delle app.

Imposta i tunnel (ognuno di questi comandi dovrà essere eseguito in una finestra separata su jump-qa):

jump-qa% ssh app-qa -R 2345:localhost:2346
jump-qa% ssh jump-dev -L 2346:app-dev:22

Ora dovresti trovare che su app-qa puoi fare telnet localhost 2345e ottenere il banner ssh di app-dev. È quindi possibile copiare il file di dati:

app-qa% scp -P 2345 localhost:/path/on/app-dev/data.dat data.dat