Erro ao copiar o diretório de um host remoto para outro host remoto com 'scp'

Question

Do meu laptop, estou tentando copiar um diretório de arquivos de um Raspberry Pi ( [email protected] ) para outro ( [email protected] ):

~/example$ scp -r [email protected]:~/example/files_to_send [email protected]:~/example

mas continuo recebendo esta mensagem de erro depois que eu digitei a senha para [email protected] (o host do qual o diretório deve ser copiado):

[email protected]'s password:
Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey,password).
lost connection

Eu tentei excluir as impressões digitais do ECDSA em ~/.ssh/known_hosts para cada um dos dispositivos e gerar novos, reconectando cada host novamente com ssh . Eu também assegurei que os diretórios home (e todos os seus conteúdos) tenham as permissões, o proprietário e o grupo corretos.

Além disso, se acessar o Raspberry Pi do qual estou tentando copiar ( [email protected] ) com ssh e faça o seguinte:

~/example$ scp - r files_to_send [email protected]:~/example

Funciona bem.

Gostaria de saber por que usar scp para copiar de um host remoto para outro host remoto não está funcionando.

Alguma idéia?

EDITAR

Eu descobri a opção -v para scp ; aqui sua entrada na página scp man :

Verbose mode. Causes scp and ssh(1) to print debugging messages about their progress. This is helpful in debugging connection, authentication, and configuration problems.

Então, adicionei isso ao comando, e isso indica que a autenticação para [email protected] foi bem-sucedida. No entanto, quando [email protected] tentar se autenticar em [email protected] , as seguintes mensagens serão impressas e a conexão falhará:

debug1: read_passphrase: can't open /dev/tty: No such device or address
Host key verification failed.
lost connection

    

Answer 1

Quando você executa um scp em um cliente local entre dois sistemas remotos, assim:

scp remote1:file remote2:

Você está se autenticando em remote1 do seu local, como esperado, mas é remote1 que autentica para remote2 diretamente. A transferência de arquivos NÃO é enviada através do seu cliente local como você poderia esperar.

Para informar scp no cliente para autenticação em hosts remotos e para gerenciar a própria transferência de arquivos, é necessário um sinalizador adicional:

scp -3 remote1:file remote2:

Na sua situação, espero que o primeiro Pi não tenha um login baseado em certificado que funcione sem o envolvimento manual configurado para o segundo, então a autenticação falha. (Lembre-se de que suas chaves parecem exigir uma frase secreta para serem desbloqueadas, e isso não está disponível no primeiro Pi quando ele tenta se comunicar com o segundo).

OK, para que eu possa repetir seu problema quando não tiver uma configuração de autenticação baseada em certificado. Parece que para transferir entre dois sistemas remotos, você deve ter autenticação baseada em certificado (ou seja, não é necessária senha).