Eu tenho um arquivo grande no servidor onee quero copiá-lo para o servidor twousando scp. Eu tenho as chaves configuradas corretamente e posso usar o ssh / scp nos dois 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:

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

mas eu consegui:

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

Nós não temos DNS aqui (não me pergunte o porquê), 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 onepara minha estação de trabalho e depois para two, ele funcionará bem:

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

Ao usar endereços IP diretamente, conforme sugerido no comentário, obtive:

$ 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 - foi apenas um "gatilho" para esse problema, pois não havia como armazenar bigfile.tar.gzna minha estação de trabalho. O problema ocorre independentemente do tamanho do arquivo.

Questão:

Por que o comando:

scp oneremote:file secondremote:file

gera um erro, independentemente de estar usando .ssh/configalias ou diretamente usando endereços IP?

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

Encontrei uma razão para o fracasso: 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 envia imediatamente para dois , agindo como um relé.

Claramente não é esse o caso, porque uma -vopção simples revelou que de fato se conecta a um e de um tenta se conectar a dois . O que obviamente não é possível porque o servidor um não deve se conectar a dois .

Tubo simples

Tente o seguinte:

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

O primeiro deve enviar o conteúdo do arquivo para a sua máquina, enquanto o segundo deve enviá-lo para a segunda máquina. Eu calculava uma soma de verificação nos dois extremos após a transferência, para garantir que nada se perdesse ou se detestasse ao longo do caminho.

Túneis elaborados

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

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

Depois, você pode abrir uma conexão on onea máquina localhostda porta 5001e ele será encaminhado duas vezes e acabar como uma conexão on twoa localhostporta 22. Esta é a porta ssh, então você pode usá-la para outro scp, ou para rsync, ou o que for. Você também pode iniciar um rsyncservidor twoe encaminhar a porta 873 em vez de 22. Ou pode usar ncnos dois lados para transferir dados brutos, usando um número de porta arbitrário.

O principal benefício da 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 rsynccaso.

O crédito total para esta resposta está disponível em /superuser//a/602436/142948

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

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

-3: Cópias entre dois hosts remotos são transferidas pelo host local. Sem essa opção, os dados são copiados diretamente entre os dois hosts remotos.

http://www.openbsd.org/cgi-bin/man.cgi?query=scp&sektion=1

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

Como você tem acesso de usuário ao servidor de origem (um), por que não fazer login e executar seu comando scp nesse servidor diretamente ... Se você se preocupa com a demora, inicie o comando dentro de um e, em screenseguida, desconecte-o da tela com Ctrl+a de deixe correr.

No entanto, se você deve fazer isso em sua estação de trabalho, e as chaves SSH da origem para o servidor de destino estiverem funcionando bem, envie o scpcomando como parâmetro de um sshcomando, como:

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

Procurando a mensagem de erro: "Falha na verificação da chave do host". parece ser a coisa mais direta a se fazer aqui. Encontrei estas perguntas e respostas no askubuntu intitulado: Problema de conexão SSH com o erro "Falha na verificação da chave do host ..." .

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

$ ssh-keygen -R hostname

Onde hostnameestaria o endereço IP ou o nome do servidor do qual você está tentando se conectar. A propósito, todos os itens acima estariam no host dois .