scp de um servidor remoto para outro servidor remoto

Question

Eu tenho um arquivo grande no servidor one e quero copiá-lo para o servidor two usando scp . Eu tenho as chaves de configuração corretamente e posso ssh / scp para ambos os servidores da minha área de trabalho.

O arquivo que eu preciso copiar é maior que o espaço livre no disco rígido da minha estação de trabalho, então eu queria fazer:

scp one:/opt/bigfile.tar.gz two:/opt/bigfile.tar.gz

mas eu tenho:

ssh: Could not resolve hostname one: Name or service not known

Nós não temos DNS aqui (não me pergunte por que), então eu tenho isso no meu ~ / .ssh / config:

Host one
    Hostname        <IP address of server one>
    User            jspurny

Host two
    Hostname        <IP address of server two>
    User            jspurny

Se eu tentar com um arquivo menor e transferi-lo de one para minha estação de trabalho e, em seguida, para two , tudo funcionará bem:

scp one:/opt/smallerfile.tar.gz .
scp smallerfile.tar.gz two:/opt/

Ao usar endereços IP diretamente, como sugerido no comentário, recebi:

$ scp jspurny@<one's IP>:bigfile.tar.gz jspurny@<two's ip>:bigfile.tar.gz
Host key verification failed.
lost connection

Não é um problema:

O tamanho não é um problema aqui - era apenas um "gatilho" para esse problema, pois não havia como armazenar bigfile.tar.gz na minha estação de trabalho. O problema ocorre independentemente do tamanho do arquivo.

Pergunta:

Por que o comando:

scp oneremote:file secondremote:file

gera um erro independentemente do uso de .ssh/config aliases ou diretamente usando endereços IP?

Resolvido - meio que - ainda procurando explicação - dividi o bigfile em arquivos menores e os transferi um por um através da minha estação de trabalho. Eu ainda estou me perguntando por que isso não funcionou. Então, eu ainda apreciaria alguma explicação do que estava errado ...

Encontrei um motivo pelo qual ele falha: Parece que eu estava sendo tolo. Eu pensei que o comando

scp one:file two:file

estava criando duas conexões para cada servidor e, em seguida, recebia dados de um e os enviava imediatamente para dois e, assim, agia como um relé.

Isso claramente não é o caso, porque uma simples opção -v revelou que, na verdade, apenas se conecta a um e de um ele tenta se conectar a dois . O que obviamente não é possível porque o servidor um não deve se conectar a dois .

    

Answer 1

Tubo simples

Tente isto:

ssh one 'cat file' | ssh two 'cat > file'

O primeiro deve enviar o conteúdo do arquivo para sua máquina, enquanto o segundo deve enviar para a segunda máquina. Eu calcularia uma soma de verificação em ambas as extremidades após a transferência, para garantir que nada se perdesse ou fosse distorcido ao longo do caminho.

Túneis elaborados

Para aplicativos mais elaborados, você pode usar túneis ssh. Por exemplo, você poderia tentar algo assim:

ssh -R 5001:127.0.0.1:5002 one
ssh -L 5002:127.0.0.1:22 two

Em seguida, você pode abrir uma conexão em one para a máquina localhost port 5001 e ela será encaminhada duas vezes e terminará como uma conexão em two to localhost port 22 . Esta é a porta ssh, então você pode usar isso para outro scp, ou para o rsync, ou o que for. Você também pode iniciar um rsync server em two e encaminhar a porta 873 em vez de 22. Ou você pode usar nc em ambos os lados para transferir dados brutos, usando um número de porta arbitrário.

O principal benefício entre a abordagem acima é que você tem uma conexão tcp bidirecional entre as duas máquinas, em vez de apenas um tubo unidirecional. Dessa forma, as duas partes podem trocar informações, o que é particularmente importante no caso rsync .

    

Answer 2

O crédito total por esta resposta vai para o link

Você precisa da opção -3 para scp:

scp -3 one:/opt/bigfile.tar.gz two:/opt/bigfile.tar.gz

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

link

Caso contrário, o segundo apelido "dois" está sendo resolvido no host "one" , que pode não existir.

    

Answer 3

Como você tem acesso de usuário ao servidor de origem (um), por que não fazer login e executar seu comando scp diretamente nesse servidor ... Se você se preocupa que demore, inicie o comando dentro de screen . desanexar da tela com Ctrl+a d e deixar que ela seja executada.

No entanto, se precisar fazer isso em sua estação de trabalho e as chaves SSH da origem para o servidor de destino estiverem funcionando bem, envie o comando scp como o parâmetro de um comando ssh , como:

ssh user@source 'scp /path/to/file user@destination:/path/to/file'

    

Answer 4

Pesquisando a mensagem de erro: "Falha na verificação da chave do host". parece ser a coisa mais simples de se fazer aqui. Eu encontrei este Q & A em askubuntu intitulado: problema de conexão SSH com Falha na verificação da chave do host… ".

Uma das respostas para as perguntas e respostas sugeriu que o problema ocorreu com uma entrada conflitante no seu ~/.ssh/known_hosts Arquivo. Você pode excluir as entradas problemáticas desse arquivo usando qualquer editor de texto ou usar este comando para remover entradas:

$ ssh-keygen -R hostname

Em que hostname seria o endereço IP ou o nome do servidor do qual você está tentando se conectar. Todos os itens acima estariam no host two pelo caminho.