Назад | Перейти на главную страницу

RSync через SSH - в разрешении отказано, даже если пользователь находится в корневой группе

Мне нужно копировать файлы между серверами через Интернет. Для этого я использую RSYNC поверх ssh. Проблема в том, что мне нужно иметь возможность передавать файлы независимо от того, где они находятся.

Я создал пользователя rsync и: usermod -G root -a rsync чтобы дать ему право читать / писать где угодно на обоих серверах.

Во время переноса я вижу такую ​​ошибку:

rsync: mkstemp "/root/.myFile.RDr2HY" failed: Permission denied (13)

Я не понимаю, что происходит.

изменить: я только что обнаружил, что в целевой папке нет доступа на запись для корневой группы. Как мне предоставить 100% доступ этому пользователю rsync? Если я изменю его uid на 0, rsync перестанет работать.

Что ты наделал, usermod -G root -a rsync, заключается в добавлении rsync пользователя в корневую группу. Это никак не влияет на большинство систем, потому что корневая группа не является особенной. Есть системы, в которых нахождение в корневой группе нужно для повышения привилегий до пользователя root, но этого никогда не бывает (корневая группа - это группа пользователей, которые могут использовать sudo, или аналогичная установка).

С точки зрения безопасности, предоставление пользователю разрешения на запись файлов в любом месте в точности эквивалентно предоставлению этому пользователю полномочий root. (Пользователь может перезаписать /bin/su, или /etc/passwd, или /usr/sbin/sshd, или любое количество других программ и баз данных, которые позволили бы ей установить себе бэкдор.)

Если вам нужно получить доступ к произвольным файлам через ssh, разрешите вход по ssh как root. Не с паролем (или длинным, случайно сгенерированным), а только с ключом (который, конечно, вам нужно будет тщательно защищать). В /etc/sshd_config, ставить

PermitRootLogin yes

Другой способ разрешить произвольный доступ к файлам - предоставить вашему пользователю rsync соответствующие разрешения через списки контроля доступа POSIX в вашей файловой системе (ах). Я написал краткое изложение унаследованных списков контроля доступа. Вот.

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

Однако я сильно подозреваю, что на самом деле вам вообще не требуется возможность размещать файлы в любом месте системы. Если это так, и вам просто нужно иметь возможность помещать их в какое-то количество произвольных мест, то ACL POSIX могут вам помочь.

Если вам действительно нужна возможность перезаписать, например, / etc / passwd с помощью этого механизма, вам следует рассмотреть другой подход. Если вы отправляете изменения конфигурации, включая учетные записи, вам будет лучше, если вы воспользуетесь системой управления конфигурацией, например кукольный или cfengine. Это позволит вам указать изменения конфигурации, которые затем будут отправлены в удаленную систему.