“Permissão negada, tente novamente” durante a transferência de arquivos com scp

Question

Eu tenho dois servidores (A e B) e minha máquina local. Estou tentando transferir um arquivo do servidor A para o servidor B.

Do servidor A:

scp ./backup.tar [email protected]:/home/public/
Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey, password).
lost connection

Do servidor B:

scp [email protected]:/home/public/backup.tar .
Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey, password).
lost connection

Mesma mensagem de erro quando tento no meu computador local. O que está acontecendo?

Isto é o que eu recebo quando tento ssh do Servidor A para o Servidor B com o sinalizador de depuração:

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/private/.ssh/identity
debug1: Trying private key: /home/private/.ssh/id_rsa
debug1: Trying private key: /home/private/.ssh/id_dsa
debug1: Next authentication method: password
debug1: read_passphrase: can't open /dev/tty: No such file or directory
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
debug1: read_passphrase: can't open /dev/tty: No such file or directory
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
debug1: read_passphrase: can't open /dev/tty: No such file or directory
debug1: Authentications that can continue: publickey,password
debug1: No more authentication methods to try.
Permission denied (publickey,password).

Isso significa que não pode encontrar meu terminal? Devo mencionar que o servidor B é um subdomínio do servidor A. No entanto, meu provedor de hospedagem os vê como entidades completamente diferentes e eles não estão hospedados na mesma LPAR.

Conclusão Eu enviei um email ao meu provedor de hospedagem e parece que há um pequeno bug relacionado à versão do ssh e do sistema operacional (freeBSD). Atualmente, minha solução alternativa é (1) scp o arquivo localmente para minha máquina, em seguida, (2) scp o arquivo localmente para o segundo servidor. Isso é o que o scp -3 deve fazer, mas isso também falha.

    

Answer 1

Parece que há um problema com a configuração ssh nos servidores - você não pode ssh de nenhum deles (provavelmente por motivos de segurança).

Você pode tentar a sugestão de Stephane para fazer a transferência da sua máquina local ( scp [email protected]:/home/public/backup.tar [email protected]:/home/public/ ). Isso deve resolver o problema com a entrada do terminal (que pode ser criada propositalmente nos servidores).

Se isso não ajudar, isso significará que o provedor provavelmente não permitirá conexões ssh de saída. Nesse caso, você terá duas opções:

• peça ao provedor para ativar conexões ssh de saída

ou

• transfira os arquivos pela sua máquina local:

  scp -3 [email protected]: /home/public/backup.tar [email protected]: / home / public /

Answer 2

Pelo que entendi, parece que as seguintes autenticações funcionam corretamente localhost → server.a e localhost → server.b . Então, ssh server.a funciona e ssh server.b funciona. As conexões server.x → server.y falham por causa de algum problema estranho com o procedimento 'ler senha' nos servidores.

A solução mais fácil seria configurar as chaves ssh para se conectarem automaticamente de um servidor para o outro:

server.a$ ssh-keygen   #use default answers and empty passphrase
server.a$ ssh-copy-id server.b

Isso permite que server.a → server.b conexões com autenticação de chave. Faça o mesmo em server.b para a outra direção.

Depois disso, espero que scp trabalhe com autenticação automática, evitando o problema da "senha de leitura".