Как указать вариант подключения к общему ресурсу windows/samba для монтирования?

Я знаю, что это старый пост, но на всякий случай, он может помочь другим людям...

Вы должны различать 2 вещи:

  • , который устанавливает SSH-соединение .
  • которому удаленному пользователю принадлежат файлы , которые вы хотите скопировать.

Обзор

(srcmachine)  (rsync)   (destmachine)
  srcuser    -- SSH -->   destuser
                             |
                             | sudo su jenkins
                             |
                             v
                          jenkins

Допустим, вы хотите выполнить rsync:

  • Из :
    • Машина:srcmachine
    • Пользователь:srcuser
    • Каталог:/var/lib/jenkins
  • К :
    • Машина:destmachine
    • Пользователи с:destuserпо устанавливают соединение SSH .
    • Каталог:/tmp
    • Конечный владелец файлов:jenkins.

Решение

rsync --rsync-path 'sudo -u jenkins rsync' -avP --delete /var/lib/jenkins destuser@destmachine:/tmp

Пояснения

     --rsync-path=PROGRAM    specify the rsync to run on the remote machine

Хитрость заключается в том, чтобы указать запустить rsyncна удаленной машине с другим пользователем (jenkins), а не с тем, который устанавливает SSH-соединение(destuser).

Требования

SSH-доступ

(srcmachine)         (rsync)   (destmachine)
  srcuser           -- SSH -->   destuser

[~/.ssh/id_rsa]                [~/.ssh/authorized_keys] <-- "id_rsa.pub" inside
[~/.ssh/id_rsa.pub]

Не забудьте ограничить права на~/.ssh:

chmod 700 ~/.ssh

sudoer дляdestuser

У destuserдолжны быть права на выполнение sudo -u jenkins rsync.

Как правило, мы устанавливаем destuserкак член sudoers. Для этого на root@destmachine:

cat > /etc/sudoers.d/destuser << EOF
destuser ALL=(ALL) NOPASSWD:ALL
EOF

Чтобы проверить это до rsync, вы можете войти в destuser@ destmachineи запустить это:

sudo su jenkins
echo $USER

Если возвращается:

jenkins

это означает, что вы вошли в систему как пользователь jenkins, и это означает, что ваша команда rsyncтакже будет работать, потому что работает привилегия перехода к jenkins.

Примечание о плохом решении :установить SSH-соединение с целевым пользователемjenkins

Почему бы нам просто не сделать это?

(srcmachine)         (rsync)   (destmachine)
  srcuser           -- SSH -->    jenkins

[~/.ssh/id_rsa]                [~/.ssh/authorized_keys] <-- "id_rsa.pub" inside
[~/.ssh/id_rsa.pub]

, потому что jenkinsявляется «служебной» учетной записью, что означает, что она запускает службу, которая предоставляет порт(80или около того )для внешнего HTTP-доступа,и это означает, что ВОЗМОЖНО, что существует нарушение безопасности через службу Jenkins через HTTP для получения доступа.

Вот почему у нас есть www-dataпользователь и ему подобные для запуска различных служб. Если их взломают через открытые порты, они мало что смогут сделать:

  • все читается -только у них.
  • за исключением записи в /var/log/THE_SERVICE.

Таким образом, предоставление доступа по SSH для пользователя jenkinsподвергает поверхностной атаке (, и то же самое относится к доступу по SSH как root!! ).

Кроме того, если вы хотите выполнить rsync от имени другого пользователя (root, www-dataи т. д. ), вам придется скопировать открытый ключ SSH-ключа в эти учетные записи (проблемные ).

Хорошее решение:Вы должны установить SSH-доступ как можно меньшему количеству учетных записей пользователей (destuser), которые МОГУТ эскалировать до нужной вам «служебной» учетной записи (jenkins, rootи т. д. ).

0
13.11.2020, 23:44
0 ответов

Теги

Похожие вопросы