Выполнять скрипт от имени пользователя root при каждом входе в систему через ssh

Question

Есть ли способ, которым я могу выполнить скрипт, скажем, abc.sh ; как пользователь root при каждом входе в систему через SSH?

Я прошел через аналогичный вопрос, который говорит, чтобы добавить выполнение скрипта в файл .bashrc . Это не очень полезно, так как я должен был бы добавить его в конфигурационный файл каждого пользователя. Кроме того, у них все еще была бы возможность удалить это.

Выполнение с правами root не так важно, как отказ пользователю в возможности остановить его выполнение. ОС Debian, если это поможет.

Answer 1

Вы можете добавить вызов в /etc/bash.bashrc - он обрабатывается при каждом входе в Bash, поэтому, если ваши пользователи используют Bash в качестве оболочки, он должен запустить скрипт.

Answer 2

Это поздний ответ, но вы можете выполнить его при каждом входе в систему И запустить его от имени пользователя root (или любого другого пользователя), выполнив следующие действия:

1. Напишите ваш скрипт с командами, которые вы хотите запустить от имени пользователя root, и сохраните его, например, как /path/to/root-script.sh .

2. Сделайте root (или нужного пользователя) владельцем скрипта.

   chown root:root /path/to/root-script.sh`
   

3. Установите бит setuid в сценарии с другими необходимыми разрешениями. (убедитесь, что он не доступен для записи и т. д.)

   chmod 4755 /path/to/root-script.sh
   

   4 означает установить бит setuid, который будет запускать скрипт как владельца скрипта. Это то, что sudo использует для обеспечения выполнения от имени пользователя root.

4. Чтобы убедиться, что он запускается при каждом входе в систему, запустите sticky-bit-set root-script.sh из /etc/profile . /etc/profile должен запускаться независимо от используемой пользователем оболочки. Обратите внимание, что это будет применяться только к интерактивным входам.

Редактировать Как отметил Скотт в комментариях, это решение обычно НЕ работает на любой современной системе с любым сценарием shebang, кроме Perl <5.12.0. Современные ядра игнорируют сценарии с битом setuid, если они не были исправлены, что не рекомендуется из соображений безопасности.

Скорее всего, setuid обычно работает только с скомпилированными двоичными файлами и [старыми версиями Perl] [ https://stackoverflow.com/questions/21597300/can-i-setuid-for-perl-script], которые можно использовать (Perl <5.12.0) с suidperl .

Этот вопрос Unix/Linux SE содержит исчерпывающий ответ о том, почему setuid игнорируется для сценариев shebang, с его обобщенным TL; DR:

Сетуид Шебанг небезопасен, но обычно игнорируется. Если вы запускаете программу с привилегиями (либо через sudo, либо через setuid), пишете собственный код или perl, либо запускаете программу с помощью оболочки, которая дезинфицирует среду (например, sudo с опцией env_reset).

Answer 3

OpenSSH поддерживает конфигурационную переменную ForceCommand которая может быть установлена на путь сценария, который

1. Делает что-то административное - подробности см. Ниже.

2. Вызовы

   $(SHELL) -c "$SSH_ORIGINAL_COMMAND"
   

   или же

   eval "$SSH_ORIGINAL_COMMAND"
   

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

Теперь проблема в том, что принудительная команда выполняется с учетными данными вошедшего в систему пользователя. Чтобы бороться с этим, достаточно использовать своего рода IPC для связи с процессом-демоном, работающим от имени пользователя root. Unix-доменные сокеты кажутся мне лучшим выбором, поскольку они действительно позволяют передавать учетные данные до того, как произойдет фактический обмен данными (с помощью getsockopt(SO_PREERCRED)). Недостатком является то, что вам придется написать пару инструментов, чтобы сделать это (ну, клиентская часть может быть обработана socat).

Смотрите также эту тему.