У меня есть эта команда для резервного копирования удаленной машины. Проблема в том, что мне нужны права root для чтения и копирования всех файлов. У меня нет root-пользователя, включенного по соображениям безопасности, и я использую sudoUbuntu. Нужна ли мне какая-нибудь крутая труба или что-то для этого?
rsync -chavzP --stats user@192.168.1.2:/ /media/backupdisk/myserverbackup/
Ответы:
Я бы порекомендовал вам просто использовать учетную запись root. Если вы установите его так:
sshd_configна целевой машине PermitRootLogin without-password.ssh-keygenна машине, которая извлекает резервную копию, для создания закрытого ключа SSH (только если у вас еще нет ключа SSH). Не устанавливайте парольную фразу. Google учебник, если вам нужны детали для этого, должно быть много./root/.ssh/id_rsa.pubрезервной машины к /root/.ssh/authorized_keysвашей целевой машине.тогда полученная установка должна быть довольно безопасной.
sudo, особенно в сочетании с NOPASSWDрекомендациями в комментариях, не имеет никаких преимуществ по сравнению с использованием только учетной записи root. Например, это предложение:
добавьте следующее в ваш
/etc/sudoersфайл:rsyncuser ALL= NOPASSWD:/usr/bin/rsync
по сути, дает rsyncuserправа root в любом случае. Ты спрашиваешь:
@MartinvonWittich Легко получить полноценную корневую оболочку, потому что
rsyncвыполняется сsudo? Пройдите, пожалуйста.
Ну просто. С рекомендуемой конфигурацией, rsyncuserтеперь может работать rsyncот имени пользователя root даже без запроса пароля. rsyncэто очень мощный инструмент для работы с файлами, поэтому теперь у rsyncuserнего есть очень мощный инструмент для работы с файлами с правами root. Поиск способа использовать это занял у меня всего несколько минут (протестировано на Ubuntu 13.04, требуется dash, bashне работает):
martin@martin ~ % sudo rsync --perms --chmod u+s /bin/dash /bin/rootdash
martin@martin ~ % rootdash
# whoami
root
# touch /etc/evil
# tail -n1 /etc/shadow
dnsmasq:*:15942:0:99999:7:::
Как видите, я создал себе корневую оболочку; whoamiопределяет мою учетную запись как root, я могу создавать файлы /etc, и я могу читать из /etc/shadow. Мой эксплойт состоял в том, чтобы установить бит setuid в dashдвоичном файле; это заставляет Linux всегда запускать этот двоичный файл с разрешениями владельца, в данном случае root.
Наличие настоящего корня не [рекомендуется] по уважительным причинам. - Redanimalwar 15 часов назад
Нет, неуклюже работать с учетной записью root в ситуациях, когда это абсолютно уместно, не по уважительным причинам. Это просто еще одна форма программирования грузового культа - вы на самом деле не понимаете концепции, лежащей в основе sudo vs root, вы просто слепо применяете убеждение «root is bad, sudo is good», потому что вы где-то читали это.
С одной стороны, бывают ситуации, когда sudoопределенно подходящий инструмент для работы. Например, когда вы в интерактивном режиме работаете над графическим рабочим столом Linux, скажем, Ubuntu, тогда необходимость в использовании sudoвполне подходит в тех редких случаях, когда вам иногда требуется доступ с правами root. Ubuntu преднамеренно имеет отключенную корневую учетную запись и вынуждает вас использовать ее sudoпо умолчанию, чтобы запретить пользователям просто всегда использовать корневую учетную запись для входа в систему. Если пользователь просто хочет использовать, например, веб-браузер, то вход в систему от имени пользователя root будет опасным и, следовательно, отсутствие учетной записи root по умолчанию не позволяет глупым людям делать это.
С другой стороны, существуют ситуации, подобные вашей, когда автоматизированному сценарию требуются права суперпользователя для чего-либо, например, для создания резервной копии. Теперь использование sudoдля обхода корневой учетной записи не только бессмысленно, но и опасно: на первый взгляд rsyncuserвыглядит как обычная непривилегированная учетная запись. Но, как я уже объяснил, злоумышленнику будет очень легко получить полный root-доступ, если он уже получил rsyncuserдоступ. По сути, теперь у вас есть дополнительная учетная запись root, которая совсем не похожа на учетную запись root, что не очень хорошо.
/root/.ssh/authorized_keysили даже создать несколько корневых учетных записей с разными домами, чтобы у каждого пользователя была своя оболочка, дом и .ssh/authorized_keys:)
sshdобычно не регистрируется, какой авторизованный ключ использовался для подключения к учетной записи, поэтому, если вы подключитесь как bobтогда sudo, вы получите лучший контрольный журнал, чем при rootнепосредственном подключении bobс помощью ключа.
Используйте --rsync-pathопцию, чтобы заставить удаленную rsyncкоманду работать с sudoпривилегиями. Ваша команда должна быть, например:
rsync -chavzP --rsync-path="sudo rsync" --stats user@192.168.1.2:/ .
Если sudoвас попросят ввести пароль, вам следует избегать его, либо используя NOPASSWDпривилегию с удаленной учетной записью пользователя (бессмысленно для root, может иметь смысл в других случаях использования), либо если вы не хотите этого делать:
Убедитесь, что опция tty_ticketsотключена для пользователя, которого вы используете, запустив, например, sudo visudo -f /etc/sudoers.d/local-rsync
и введя:
Defaults:your.username.for.rsync !tty_tickets
Убедитесь, что эта опция requirettyотключена для пользователя, которого вы используете - по умолчанию она может быть отключена. Метод такой же, как и выше.
Заполните sudoпароль на удаленной машине, запустив, например,
ssh -t user@192.168.1.2 sudo
sudoпароль, а не sshпароль
sudo /usr/bin/rsyncбез запроса пароля; проверьте, man sudoersкак это сделать; Вы можете создать дополнительного резервного пользователя для этого.
sudo /usr/bin/rsyncзапуск без указания пароля, добавьте в /etc/sudoersфайл следующее: rsyncuser ALL= NOPASSWD:/usr/bin/rsyncЭто позволит пользователю rsyncuser (как уже упоминалось выше, лучше создать отдельного пользователя резервной копии) с нужным именем пользователя.
rsyncсути всегда имеет права root; вероятно, очень легко получить полноценную корневую оболочку в этом аккаунте. Я думаю, что лучше всего использовать реальную учетную запись root.
echo "password" | somethingя на самом деле никогда не использовал это, и согласен с проблемами безопасности, связанными с разрешением sudoless выполнения rsync (также здесь не предлагается), плохой. Что tty_ticketsя на самом деле понятия не имею, кажется необходимым и проблемой безопасности. Это будет работать безопасно, ничего не настраивая, просто запустив sodo в ssh и затем выполнив команду, верно? Но так как я задал этот вопрос в целях написания сценариев, я полностью согласен с тем, что ssh без ключа на основе ключей является безопасным и правильным. Вместо этого я принял ответ Мартинса.
Одним из простых способов сделать это является использование графической ssh-askpassпрограммы с sudoэтим, что позволяет обойти тот факт, что sudoон не подключен к терминалу и позволяет безопасно вводить пароль:
rsync -chavzPe 'ssh -X' --stats \
--rsync-path='SUDO_ASKPASS=/usr/lib/ssh/x11-ssh-askpass sudo -A rsync' \
user@192.168.1.2:/ .
Конечно, ssh-askpassпрограмма должна быть установлена в указанном месте, и вы должны запустить сеанс X на компьютере, на котором вы работаете. В программе есть несколько вариантов, ssh-askpassкоторые также должны работать (версии Gnome / KDE). Также графическая sudoзамена программы, как gksuили kdesudoдолжно также работать.
rsync --rsh='ssh -X' --rsync-path='gksudo -- rsync' user@host:/ .не работает rsync error: syntax or usage error (code 1) at main.c(1634) [server=3.1.1], О, Ubuntu отправляет gnome-ssh-askpass, но это /usr/bin/ssh-askpassвместо /usr/lib/ssh/x11.... Так что сработало :)
ssh-askpass. Мне просто нужно выяснить значение -chavzPe, было бы здорово изложить это как длинные варианты.
xeyesиспользуя SSH.
Если у вашего пользователя уже есть привилегии sudo, которые защищены паролем, я бы оставил их как есть и добавил только раздел для использования rsync без пароля:
%admin ALL=(ALL) ALL
%admin ALL= NOPASSWD:/usr/bin/rsync
Я столкнулся с этой проблемой сегодня и решил ее без необходимости изменения файлов конфигурации или предоставления полномочий на уровне root для учетных записей пользователей. Моя особая установка состояла в том, что пользователь Aна машине fooдолжен был скопировать все пользовательские каталоги с fooкомпьютера на компьютер barв backupкаталоге, которым Aвладел пользователь . (Пользователь Aимеет права sudo на foo.)
Команда, которую я использовал, приведена ниже. Он был вызван пользователем Aв /homeкаталоге foo.
sudo rsync -avu -e "ssh -i /home/A/.ssh/id_rsa -l A" * B:/home/backup
Это работает Rsync , как Судо так , чтобы все каталоги пользователей на fooможет быть доступна , но он говорит Rsync использовать SSH к машине доступа с barпомощью пользовательских Aучетных данных «s. Мои потребности немного отличались от приведенного выше вопроса, но это позволило мне быстро получить резервную копию всех пользовательских каталогов на конкретной машине, которой я управляю, без вреда для конфигурации системы.
-iопцию ssh. Вы можете использовать, --rsync-path="sudo /usr/bin/rsync" если у вас есть sudo на машине bar. Это тогда делает чтение как root@fooи запись как root@bar, но передает через A@foo-> B@bar. Спасибо!
Запуск rsync в качестве демона на целевой машине позволяет вам делать то, что вы хотите.
Мое решение заключается в использовании, --rsync-path="sudo rsync"но он запрашивает пароль, обходной путь:
rsync -chavzP --stats --rsync-path="echo <SUDOPASS> | sudo -Sv && sudo rsync" user@192.168.1.2:/ .
$( cat my_password.txt )который немного лучше, но обычно предпочтительнее настроить разрешения на обоих концах и / или использовать ключи SSH таким образом, чтобы пароли не требовались в CLI
rootучетную запись в первую очередь.sudoособенно в сочетании сNOPASSWDрекомендациями в комментариях, на самом деле не улучшает безопасность вашей машины.