сервис systemd, для которого нужен .ssh/id_dsa пароль

Это - известная проблема, и ошибка даже зарегистрирована. Один из разработчиков даже узнал причину и выбор, что сделать


Ошибка была исправлена в Сновещательном и загружается в архивах

Ошибка была исправлена в нашем официальном PPA. Сделайте обновление

7
28.10.2012, 00:30
3 ответа

Необходимо поместить файлы идентификационных данных, содержащие не зашифрованный закрытый ключ в ~/.ssh каталог пользователя сервис работает. Кроме того, необходимо установить переменную Домашней среды для него, например, если это выполняется как корень:

ExecStart=/usr/bin/env HOME=/root /usr/bin/screen -S smd-loop-win -md "smd-loop"

С другой стороны, если Вы имеете контроль на как smd-loop вызывает ssh можно добавить -I опция сказать ssh файл идентификационных данных для использования.

В любом случае файл идентификационных данных должен принадлежать этому пользователю и должен быть доступным этим пользователем только (chmod 0400 ~/.ssh/id*) .

2
27.01.2020, 20:18
  • 1
    Спасибо!, чтобы быть корректным env должен быть /usr/bin/env потому что systemd не знает где env . также, команда на самом деле smd-loop, smd-loop-win название созданного экранного экземпляра. –  romeovs 27.10.2012, 22:33

Если у Вас только должна быть сервисная работа, в то время как Вы зарегистрированы, заставьте ее соединиться с ssh-agent то, что Вы запускаете со своей сессии. Самый легкий способ сделать это должно использовать фиксированный путь для сокета агента. Установите SSH_AUTH_SOCK переменная среды к чему-то как /home/romeovs/.ssh/darkstar.agent.socket и в systemd задании и в Вашем .profile. Обратите внимание на это, если Ваше распределение запускается ssh-agent процесс для Вас, Вы, возможно, должны уничтожить его, или оставить его неиспользованным и заменить его Вашим собственным. Если SSH_AUTH_SOCK переменная присутствует в среде, ssh-agent использует путь, который это содержит для его сокета. Затем когда Вы входите в систему, работаете ssh-add на Вашем закрытом ключе и задании сможет использовать его.

Если у Вас должна быть сдельная работа все время, я рекомендую создать определенный ключ без пароля с этой целью (ssh-keygen -t rsa -f ~/.ssh/smd.id_rsa -N ''), и разрешите его только выполнять определенную команду на сервере при помощи a command= и from= ограничения в ~/.ssh/authorized_keys файл на сервере. from= опция означает, что ключ только допустим для попыток входа в систему от определенные хосты, и command= указывает команду, которая выполняется вместо команды, указанной клиентом.

ssh-rsa AAAA…== romeovs@darkstar no-agent-forwarding no-port-forwarding no-x11-forwarding from="romeovs@darkstar.example.com" command="somecommand --foo"

Команда выполняется Вашей оболочкой входа в систему. Если необходимо передать параметры той команде, у Вас есть два варианта:

  • Исходная команда, предпринятая клиентом, находится в SSH_ORIGINAL_COMMAND переменная среды. Остерегайтесь заключения в кавычки проблем, при попытке проанализировать его.
  • Несколько переменных среды передаются клиентом. Точный набор зависит от конфигурации сервера (AcceptEnv директива в sshd_config файл).
3
27.01.2020, 20:18

Я генерировал бы собственный ssh-ключ без пароля для того сервиса.

В целевой системе (системах) я затем использовал бы "команду =" в authorized_keys для ограничения использования того ключа к единственной команде.

После этого для инициирования целевой команды просто необходимо соединиться с сервером - Вы не должны указывать ничто иное (не событие команда) больше.

2
27.01.2020, 20:18

Теги

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