Unison и sudo user

Очевидно, разрешить сверхпользователю доступ по SSH.

Очивидно, что доступ не просто так закрыт для сверх пользователя.

очевидно по дефолту в sshd разрешено логиниться под root только с использованием ключей. с ключами всё становится проще.

Ну вот, а вам его надо не просто так разрешить.

[сарказм]товарищи, я весьма благодарен вам за то, что вы открыли Америку для меня касательно ключей и дефолтных настроек sshd[/сарказм], не сочтите за грубость, но я задал весьма простой вопрос - как работать с unison'ом без доступа по руту с рутовыми файлами? Доступ по руту невозможен из-за некоторых, независящих от меня, факторов, а также регламента безопасности. Возможно есть альтернативы для двусторонней синхронизации?

Всем спасибо. Решил вопрос самопальным скриптом

но я задал весьма простой вопрос - как работать с unison'ом без доступа по руту с рутовыми файлами?

1. Хорошо, вот вам простой ответ. Работать с рутовыми файлами без доступа к руту ни при помощи Унисона, ни при помощи любой другой программы нельзя.

2. Если же это не так, и на самом деле сверхпользовательские права у вас есть, но присутствует лишь валяющееся на пути бессмысленное ограничение (которое никакой «безопасности» служить не может, потому что оно бессмысленное), то его необходимо просто убрать (возможно, временно). Права у вас для этого есть. Если нет, то см. п. 1.

1. эту возможность предоставляет sudo, в котором можно сделать гибкую настройку для непривилегированного пользователя, а не давать всем подряд доступ по руту. 2. Права есть через sudo. Ограничение не является бессмысленным, если вам не понятна логика, то см. п.1.

эту возможность предоставляет sudo

Ну то есть есть у вас сверхпользовательские права.

в котором можно сделать гибкую настройку для непривилегированного пользователя

Правда? Мне казалось, что наоборот — с помощью sshd(8) можно сделать относительно гибкую настройку, загнав пользователя в chroot, а с помощью sudo(8) — нет.

а не давать всем подряд доступ по руту

Вы, кажется, совершенно упускаете, как работает SSH.

Ограничение не является бессмысленным, если вам не понятна логика

Мне непонятна логика? Кто вам сказал такую глупость? Мне непонятен смысл ограничения; и это потому, что (по мере убывания вероятности):
— это ограничение бессмысленно,
— или вы чего-то недоговариваете,
— или я не знаю чего-то общеизвестного.

rsync умеет использовать sudo на удаленном сервере, но видимо не умеет делать двусторонней синхронизации, умеет ли unison работать через sudo?

Да, от прочтения всего вышесказанного (особенно про какой-то сверхсекретный «самопальный скрипт») у человека, которому это действительно нужно¹, может сложиться впечатление, будто бы я говорю, что это невозможно.

Тогда как это должно быть вполне возможно, ибо «уметь» ни rsync’у, ни unison’у тут абсолютно нечего. Все, что имеется в виду, — это пропись пути к исполняемости на удаленной машине (--rsync-path='sudo -u user rsync').

У Унисона ключ с таким же значением, как несложно узнать из документации, называется servercmd:

-servercmd 'sudo -u user unison'

Не проверял, так что если он будет ругаться на пробелы, то все, что надо сделать (помимо того, что написать багрепорт) — это перенести эту строчку в сценарий и прописать путь до него.

____
¹ Например потому, что сверхпользовательских прав у него нет, и sudo (или pkexec, или что-нибудь еще) он делает в другого непривилегированного пользователя.

Ну то есть есть у вас сверхпользовательские права.

на выполнение каких то определенных бинарников - да.

Мне непонятен смысл ограничения

Как я уже сказал, есть регламент, по которому вход под рутом на сервера запрещен.

Правда? Мне казалось, что наоборот — с помощью sshd(8)

каждый решает задачи/проблемы по своему, возможно в будущем я тоже приду к такому мнению.

Вы, кажется, совершенно упускаете, как работает SSH.

Возможно. Я не гуру линукса, пока только учусь.

особенно про какой-то сверхсекретный «самопальный скрипт»

Нет там ничего сверхсекретного, обычный скрипт rsync+проверка mtime.

У Унисона ключ с таким же значением, как несложно узнать из документации, называется servercmd

Вот за это спасибо.

Как я уже сказал, есть регламент, по которому вход под рутом на сервера запрещен.

Господи... Вот с этого и надо было начинать — что у вас есть какой-то идиотский регламент, которому вас заставляют следовать.

Ну то есть есть у вас сверхпользовательские права.

на выполнение каких то определенных бинарников - да.

rsync(1) — не просто «определенный бинарник», это не ping(8) и не mount(8), которые всем можно и нужно запускать от именно от сверхпользователя; это программа, которой можно приказать прочитать *любой* файл, и записать *любой* файл. Если злоумышленнику по какой-то причине этого недостаточно, то следует вспомнить, что «любой» включает в себя сам rsync, так что можно сперва перезаписать его чем угодно, а потом это что угодно выполнить.

Таким образом ограничение существует только в небогатой фантазии писавшего регламент, а на самом деле у того, кто имеет доступ к вашему ключу, есть *полный* сверхпользовательский доступ.

Правда? Мне казалось, что наоборот — с помощью sshd(8)

каждый решает задачи/проблемы по своему

Это *не* решает задачу. Ограничивать перечень исполняемостей rsync’ом (или любой другой программой сходных свойств) имеет смысл только тогда, когда сессия загнана в chroot. sshd(8) это сделать позволяет, sudo(8) — нет.

Я не гуру линукса, пока только учусь.

К Линуксу® все это не имеет никакого отношения.

особенно про какой-то сверхсекретный «самопальный скрипт»

Нет там ничего сверхсекретного, обычный скрипт rsync+проверка mtime.

Ну и почему же тогда не обнародовали? ;-)

У Унисона ключ с таким же значением, как несложно узнать из документации, называется servercmd

Вот за это спасибо.

Уй-й... Оно хоть работает?

Господи... Вот с этого и надо было начинать

Ведь с этого и начиналось Unison и sudo user (комментарий).

Таким образом ограничение существует только в небогатой фантазии писавшего регламент
Это *не* решает задачу

согласен

Ну и почему же тогда не обнародовали? ;-)

Да не вопрос, но вряд ли эта поделка кому сгодится:

  for FILE in $(cat /root/scripts/filelist)
   do
    REMOTE_IP="192.168.1.2"
    netcat -z -n  "$REMOTE_IP" 22 > /dev/null 2>&1
    if [ "$?" -eq "0" ]
     then
      LOCALMTIME=$(date -d "$(ls -l --time-style=full-iso "$FILE" | awk '{print$6,$7}')" "+%s")
      REMOTEMTIME=$(date -d "$(ssh user@"$REMOTE_IP" "ls -l --time-style=full-iso "$FILE"" | awk '{print$6,$7}')" "+%s")
      if [ "$LOCALMTIME" -lt "$REMOTEMTIME" ]
       then
       rsync -a -e "ssh" --rsync-path="sudo rsync" user@"$REMOTE_IP":"$FILE" "$FILE"
      fi
    fi
   done

Уй-й... Оно хоть работает?

Еще не проверял, судя по ману должно работать.