Copiar dados por meio do túnel SSH em vários saltos

Question

Temos dois ambientes principais em questão:

Desenvolvimento e controle de qualidade

Cada ambiente tem dois servidores:

• Caixa de salto
• Servidor de aplicativos

Para se conectar ao servidor de aplicativos, você deve se conectar primeiro à caixa de salto e, em seguida, ao SSH ao servidor de aplicativos.

Existem algumas regras em vigor, cortesia do firewall:

• Você DEVE se conectar ao servidor de aplicativos por meio da caixa de salto
• O servidor de aplicativos não pode se conectar a nenhuma das caixas de salto
• As caixas de salto estão na mesma sub-rede e podem se comunicar entre si.

Nosso problema

Temos muito conteúdo (670 GB) no DEVELOPMENT APPLICATION SERVER e precisamos fazer isso para o QA APPLICATION SERVER .

Copiar esses dados para as caixas de salto não é uma opção porque eles não têm a quantidade necessária de espaço.

Eu fiz algumas pesquisas e descobri que poderíamos fazer uma série de túneis por meio desses servidores para que pudéssemos transmitir os dados diretamente de um servidor de aplicativos para outro por meio dos túneis. No entanto, o problema que não podemos conectar à caixa de salto do servidor de aplicativos.

Temos alguma opção? Esta é uma situação desesperadora, e o tempo é essencial. Não temos tempo para baixar os dados e fazer o upload novamente. Copiar através da rede nos servidores ocorrerá rapidamente, pois é uma conexão gigabit.

    

Answer 1

De longe, a maneira mais fácil é simplesmente copiá-lo via scp. Além disso, essa sintaxe realmente funciona diferente de outras sugestões.

Você não pode bater essa sintaxe para facilitar. Ele permite que você copie recursivamente, rsync ou o que quiser, sem o incômodo de considerar canais potencialmente complexos. Esta sintaxe é intuitivamente clara, será mais facilmente suportada pelos Administradores do Sys que seguem você e não faz uso inútil do gato .

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

A partir da página man do scp : -3 As cópias entre dois hosts remotos são transferido através do host local. Sem essa opção, os dados são copiados diretamente entre os dois hosts remotos. Note que esta opção desativa o medidor de progresso.

No exemplo abaixo

• A sua estação de trabalho chama-se MacBook Pro.
• Dev Jump Box é chamado devjumpserver
• O Dev Application Server é denominado devapplicationserver
  • Está na zona DNS da LAN chamada .local
• O QA Jump Box é chamado de qajumpserver
• O QA Application Server é denominado qaapplicationserver
  • Está na zona DNZ da LAN chamada .local
• Vamos fazer uma cópia de teste de um arquivo / etc / hosts de 670GB; -)
• Supõe-se que você tenha a autenticação de chave pública SSH configurada.

Aqui está um arquivo ~ / .ssh / config que configura o acesso direto de sua estação de trabalho aos servidores de aplicativos através do salto apropriado (também conhecido como servidor bastion).

MacBook-Pro:~ barrychapman$ cat ~/.ssh/config
Host *
  ServerAliveInterval 60
Host devapplicationsever
  HostName devapplicationserver.local
  ProxyCommand ssh -i ~/.ssh/id_rsa [email protected] -W %h:%p
  User barrychapman
Host qaapplicationserver
  HostName qaapplicationserver.local
  ProxyCommand ssh -i ~/.ssh/id_rsa [email protected] -W %h:%p
  User barrychapman

MacBook-Pro:~ barrychapman$

Testando a presença de arquivo no servidor de destino, ele não estará lá.

MacBook-Pro:~ barrychapman$ ssh qaapplicationserver ls /tmp/hosts
ls: cannot access /tmp/hosts: No such file or directory
Killed by signal 1.
MacBook-Pro:~ barrychapman$

Agora vamos copiar um arquivo do servidor de aplicativos Dev para o aplicativo de controle de qualidade por meio de sua estação de trabalho.

MacBook-Pro:~ barrychapman$ scp -3 devapplicationserver:/etc/hosts qaapplicationserver:/tmp/
Killed by signal 1.
Killed by signal 1.
MacBook-Pro:~ barrychapman$

Agora, vamos verificar a presença do arquivo copiado no QA Application Server. Estará lá desta vez.

MacBook-Pro:~ barrychapman$ ssh qaapplicationserver ls /tmp/hosts
/tmp/hosts
Killed by signal 1.
MacBook-Pro:~ barrychapman$ 

Nota

Ao fechar uma conexão ProxyCommand, você verá a mensagem de aviso "Killed by signal 1". Isso é SSH derrubando a conexão ProxyCommand e não é nada para se alarmar. Você pode se livrar dele adicionando LogLevel Quiet à sua sub-rotina de configuração do host bastion.

    

Answer 2

TUBOS!

Se a internet é uma série de tubos , o Unix é uma série de canais - algo como:

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

deve funcionar.

Se você precisar percorrer mais hosts, adicione mais canais (e mais camadas aninhadas de \ -escaped quotation), conforme necessário. (Observe, no entanto, que se o pipeline / escape ficar tão complexo que você tenha que desenhar um diagrama ou recorrer a contá-lo com os dedos para determinar quantas vezes você tem que dobrar em fugas provavelmente é hora de admitir a derrota e configurar uma VPN adequada!)

    

Answer 3

Se eu entendi corretamente, você tem dois servidores de salto (jump-qa e jump-dev) protegendo dois servidores de aplicativos (app-qa e app-dev); os servidores de salto podem ssh uns aos outros; nenhuma caixa diferente do servidor de salto relevante pode ssh para o servidor de aplicativos correspondente. Os servidores de aplicativos podem ssh para noone. Um arquivo deve ser transferido de app-dev para app-qa. Ambos os servidores de salto não têm espaço para uma cópia provisória dos dados.

Você pode resolver isso com o tunelamento ssh. Nós configuramos uma conexão com um servidor de aplicativos remoto, carregando um túnel remoto que se conecta de volta a uma porta não utilizada em seu servidor de salto. Nós configuramos uma segunda conexão de um servidor de salto para o outro servidor de salto, carregando um túnel que pega a extremidade pendente da porta encaminhada remotamente do túnel um e a envia para a porta ssh do outro servidor de aplicativos.

Configure os túneis (cada um desses comandos precisará ser executado em uma janela separada em jump-qa ):

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

Agora você deve descobrir que no app-qa você pode fazer telnet localhost 2345 e obter o banner ssh do app-dev. Você pode então copiar o arquivo de dados:

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