Как может произойти сбой rsync из-за отсутствия разрешений, если удаленный вход в систему происходит с root?

Question

Я не могу придумать причину, по которой передача простого файла с помощью rsync -e 'ssh -p 19' -vvv /path/to/file root@192.168.179.3: завершается неудачно с

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)

при входе по ssh логин ssh -p 19 root@192.168.179.3 работает нормально. cat [/path/to/file] для локального файла установлено 664 а владельцем является пользователь, вызывающий rsync . Файл находится в /tmp/ .

Указание абсолютного пути в аргументе -e , т.е. rsync -e '/usr/bin/ssh -p 19' -vvv /path/to/file root@192.168.179.3: не помогает.

Я использую rsync 3.1.1 на Ubuntu 15.10.

Answer 1

Другая возможная интерпретация ssh или rsync дающая Permission denied, please try again. , Причина в том, что удаленный rsync находится в необычном месте и должен быть указан с помощью --rsync-path на стороне отправителя (см. Https://stackoverflow.com/questions/7261029/how-to-solve-rsync-error -error-in-rsync-protocol-data-stream-code-12-at-io-c # comment22193023_12286054).

Дорогие разработчики ssh , пожалуйста, прекратите эту ерунду! Номер причины ошибки, по которой Permission denied, please try again. растет и растет, пожалуйста, найдите в своем сердце, чтобы предоставить пользователям любую полезную обратную связь - вы ничего не реализовали в этом направлении, о чем я говорю, после использования ssh течение многих лет и столкнувшись с десятками очень четких и объяснимых причин для сбои, которые просто заканчиваются в Permission denied, please try again. , Никто не может этого понять!

Тот факт, что ОС выдает это сообщение и не может быть изменен, ничего не значит. Вы несете ответственность за обратную связь, которую ваше программное обеспечение предоставляет пользователю, и если в Permission denied, please try again. дано для очень простых в сообщении причин сбоя, но что-то очень неправильно - просто распечатайте remote binary not found, please use --rsync-path on the sender side ! Видите, это было не так сложно.

Answer 2

Сообщение об ошибке ничего не говорит о правах доступа к файлу. Скорее, это стандартное сообщение об ошибке ssh, в котором говорится, что сам вход не был разрешен - либо из-за неправильного пароля, либо из-за конфигурации сервера, запрещающей вход в систему пользователем root.

Обратите внимание, что между вашим "тестом" и командой rsync есть несколько отличий:

1. Вы ssh для root@1.2.3.4 , в то время как rsync подключается к root@192.168.179.3 .
2. Вы не указываете порт, таким образом, подключаясь к стандартному порту SSH 22, в то время как rsync имеет указанный порт 19. Возможно, что эти порты обрабатываются двумя отдельными демонами sshd с разными конфигурациями.

Answer 3

Просто поместите мое решение здесь на случай, если оно пригодится кому-то еще.

Я пытался использовать rsync для копирования файлов в экземпляр EC2. Эта же команда хорошо работала какое-то время, но затем сломалась. Ни одно из решений, которые я нашел в Интернете, не помогло.

Подключившись к удаленному серверу и запустив ls -l в том месте, куда я копировал, я обнаружил, что папка build была создана пользователем root, а все остальные были созданы ubuntu. Проблема с разрешениями возникла в результате попытки скопировать мою локальную папку сборки на удаленный компьютер, поэтому удаление локальной папки сборки (которую в любом случае не следовало копировать) решило эту проблему для меня.