Я долго искал ответ на этот вопрос. У меня есть настройки ключей, поэтому пароль для ssh на удаленный хост не требуется. У меня есть sudo, настроенный с этим пользователем, чтобы я мог запускать необходимые команды как root без пароля. Я использую ssh для выполнения удаленных команд всего несколько дней (какое замечательное открытие!).
Немного предыстории: сценарий, выполняемый на удаленном хосте, представляет собой типичный сценарий запуска / остановки программы. Где-то в самой программе файл журнала открывается для записи. На удаленном хосте все в порядке, если я запускаю сценарий от имени пользователя root. Если я запускаю его как пользователь, я получаю сообщение об ошибке: log4cplus:ERROR Unable to open file: appname.log. Это имеет смысл, поскольку владельцем журнала является root.
Теперь ситуация: у меня есть сценарий на моем локальном хосте, который будет подключаться по ssh к удаленному хосту, и использование sudo запустит этот сценарий. Скрипт запускается. Однако после его запуска я получаю ту же ошибку, что и выше, о файле журнала. Я пробовал следующее, и все они успешно запускают скрипт, но получаю сообщение об ошибке. Я знаю, что некоторые из них не нужны, но я хотел охватить ВСЕ базы, которые смог найти (я тоже пробовал с -t, но без разницы. Я бы не подумал, что БУДЕТ, но ...):
/usr/bin/ssh username@remotehost sh -c sudo "/etc/rc3.d/S99script start"
/usr/bin/ssh username@remotehost sh -c sudo "/etc/rc3.d/S99script start"
/usr/bin/ssh username@remotehost 'sh -c sudo "/etc/rc3.d/S99script start"'
/usr/bin/ssh username@remotehost sudo /etc/rc3.d/S99script start
/usr/bin/ssh username@remotehost "sudo /etc/rc3.d/S99script start"
/usr/bin/ssh username@remotehost sudo "/etc/rc3.d/S99script start"
/usr/bin/ssh username@remotehost 'sudo "/etc/rc3.d/S99script start"'
/usr/bin/ssh username@remotehost sudo su - -c "/etc/rc3.d/S99script start"
/usr/bin/ssh username@remotehost 'sudo su - -c "/etc/rc3.d/S99script start"'
Я знаю, что пробовал и другие вещи, но не все задокументировал. Не смейтесь над тем, что я пробую разные цитаты, я хорошо понимаю, когда их использовать, но я не делал никаких изменений, пробуя разные вещи :)
Что-то, что я заметил при запуске, это то, что если я сделаю ps -ef | grep для имени сценария, он покажет следующее:
[username's UID] 3070 3069 0 14:42 ? 00:00:00 bash -c /etc/rc3.d/S99script start
Это даже для тех, где я использую "sh -c sudo". Тот факт, что он работает как bash -c, интересен, но также интересен (я думал?), Что в нем указан UID пользователя вместо имени пользователя.
** Добавить: я также попытался создать сценарий в домашнем каталоге «username», который просто выполняет: sudo /etc/rc3.d/S99script start И я получаю тот же результат.
Вы все усложняете. ssh -t user@host sudo /path/to/command должно быть все, что вам нужно сделать (без фанк-цитирования, экранирования, запуска su и суб-оболочки - просто команда, точно такая же, как если бы вы вводили ее на удаленном конце, если бы вы запускали ее вручную).
Если вы начнете использовать более сложные команды, вам, возможно, придется перейти к цитированию и экранированию, но для чего-то такого простого в этом нет необходимости.
Обратите внимание, что -t флаг для SSH необходим, если вам нужно ввести пароль для sudo: по умолчанию SSH не выделяет tty для сеанса удаленной команды (sudo будет горько жаловаться на то, что не может получить ваш пароль). -t заставляет терминал быть выделенным так sudo есть с чем взаимодействовать.
Возможно, в вашем случае это не потребуется, но на самом деле ничего не повредит.
Во-первых, измените аутентификацию на основе ключа, чтобы ваш логин в удаленной системе был таким, как пользователь, о котором идет речь - тогда нет необходимости использовать sudo (поскольку вы уже указали, что служба не работает как root, не должно быть безопасности проблемы с автоматическим входом в систему по ключу).
во-вторых, взгляните на ForceCommand в sshd_config (5) - это обеспечивает дополнительную безопасность, если вы работаете с учетной записью службы, которая должна иметь возможность делать только одну вещь. Обратите внимание на ссылку на директиву Match.
наконец, sudo может давать неожиданные результаты при выполнении команд, которые также включают модификацию файлов в системе - вот почему такие вещи, как «sudo echo foobar >> / etc / passwd» не работают так, как вы могли бы подумать. Вероятно (хотя я не могу быть уверенным, не увидев фактический рассматриваемый сценарий) фактор в вашей текущей ситуации. следуйте моему первому предложению выше, и вы полностью обойдете эту проблему. :)