Como o rsync pode falhar devido à falta de permissões se o login remoto ocorrer com o root?

Question

Não consigo pensar em nenhum motivo pelo qual a transferência de um arquivo simples com rsync -e 'ssh -p 19' -vvv /path/to/file [email protected]: falhe com

opening connection using: ssh -p 19 -l root 192.168.179.3 rsync --server -vvve.Lsfx . .  (11 args)
Permission denied, please try again.
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.1]
[sender] _exit_cleanup(code=12, file=io.c, line=226): about to call exit(12)

quando ssh login ssh -p 19 [email protected] funciona bem. cat [/path/to/file] para o arquivo local suceeds e as permissões são 664 e owner é o usuário que invoca rsync . O arquivo está localizado em /tmp/ .

A especificação do caminho absoluto no argumento -e , ou seja, rsync -e '/usr/bin/ssh -p 19' -vvv /path/to/file [email protected]: , não ajuda.

Estou usando o rsync 3.1.1 no Ubuntu 15.10.

    

Answer 1

Outra interpretação possível de ssh ou rsync dando Permission denied, please try again. . As razões são que o controle remoto rsync está em um local incomum e precisa ser especificado com --rsync-path no lado do remetente (consulte link ).

Caro ssh devs, por favor pare com essa bobagem! O número de causa do erro que dispara o Permission denied, please try again. cresce e cresce, por favor, ache em seu coração para fornecer aos usuários qualquer feedback útil - você não implementou nada nesse sentido até agora, o que eu sou dizendo depois de usar ssh por anos e encontrando dezenas de razões muito claras e explicáveis para falhas que acabam em Permission denied, please try again. . Ninguém pode entender isso!

O fato de que o sistema operacional produz essa mensagem e não pode ser alterado não significa nada. Você é responsável pelo feedback que seu software fornece ao usuário e se Permission denied, please try again. for dado pelo muito fácil de comunicar os motivos de falha acima de algo está muito errado - apenas imprima remote binary not found, please use --rsync-path on the sender side ! Veja, isso não foi tão difícil.

    

Answer 2

A mensagem de erro não diz nada sobre as permissões de arquivo. Pelo contrário, é a mensagem de erro padrão ssh dizendo que o login não foi permitido - devido a uma senha incorreta ou a configuração do servidor não permitindo logins por root.

Note que existem várias diferenças entre o seu "teste" e o comando rsync:

1. Você ssh para [email protected] , enquanto o rsync está se conectando a [email protected] .
2. Você não especifica uma porta, conectando-se assim à porta 22 padrão do SSH, enquanto o rsync tem a porta 19 especificada. É possível que essas portas sejam manipuladas por dois daemons sshd separados, com diferentes configurações.

Answer 3

Basta colocar minha solução aqui, caso seja útil para qualquer outra pessoa.

Eu estava tentando usar o rsync para copiar arquivos para uma instância do EC2. O mesmo comando estava funcionando bem por um bom tempo, mas depois quebrou. Nenhuma das soluções que encontrei on-line realmente ajudou.

Por ssh-ing no servidor remoto e executando ls -l no local para o qual eu estava copiando, descobri que a pasta build foi criada pelo root enquanto todas as outras foram criadas pelo Ubuntu. O problema de permissões veio da tentativa de copiar minha pasta de compilação local para o remoto, então remover a pasta de compilação local (que não deveria ter sido copiada) resolveu o problema para mim.