ssh В доступе отказано только в работе cron

Question

Возникла очень странная проблема. Я создал небольшой скрипт bash, который запускает команду на удаленном хосте через ssh (используя аутентификацию с открытым ключом).

Когда я запускаю этот скрипт вручную из командной строки, он работает нормально, но когда он помещается в /etc/cron.hourly, он завершается неудачно с Permission denied, please try again. ошибка.

• Я явно установил ключ в скрипте, используя ssh -i /root/.ssh/id_rsa user@remote "command" ;
• скрипт запускается с правами root (я добавил echo `id` > /tmp/whoami.log для двойной проверки); а также
• ключ ssh не защищен паролем ...

Система является сервером Ubuntu 12.04, у меня нет большого доступа на удаленной стороне для устранения неполадок, но, как я уже сказал, работает ssh вручную или тот же скрипт bash из командной строки.

Любая идея, почему это происходит или как это исправить ??

Обновить

Оказывается, я ошибся, и ключ ssh был защищен паролем (с помощью цепочки ключей, загружающей ssh-agent), поэтому он не работал из сценария, но не при запуске из сеанса bash. . ~/.keychain/$HOSTNAME-sh в моем скрипте решил проблему (спасибо @grawity, который указал мне верное направление и дал исчерпывающий ответ).

Answer 1

Интерактивные команды и задания cron выполняются в разных средах - в частности, в интерактивном сеансе может быть запущен агент SSH или сохранен Kerberos TGT. Из-за того, что ssh назначает методы аутентификации, вы не можете быть уверены, что ваш ключ используется только потому, что вы добавили опцию -i .

• Если агент SSH работает, клиент ssh всегда пробует ключи агента, прежде чем использовать какие-либо явно указанные ключи.

• Если в сети используется Kerberos и присутствует Kerberos TGT, OpenSSH будет использовать его перед попыткой аутентификации с открытым ключом.

Я ничего не знаю о вашей среде, но обе эти возможности легко проверить:

1. Добавьте unset SSH_AUTH_SOCK и unset KRB5CCNAME перед командой ssh , затем вручную запустите измененный скрипт.

   Это не даст сценарию увидеть агента или билеты Kerberos и будет использовать только явно указанный ключ.

2. Добавьте опцию -v в ssh . Это покажет более подробную информацию о том, как происходит аутентификация.

Вы также можете добавить -oIdentitiesOnly=yes к команде ssh ; это заставит его использовать указанный ключ.

---

А если добавить советы по доступу к агенту из cron - еще лучше

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

Вы упомянули "Keychain" - это программа OS X или скрипт Linux? (Я не очень разбираюсь в архитектуре Mac OS X, но AFAIK значительно затрудняет доступ к ssh-агенту пользователя с помощью cronjob ...)

Answer 2

Другим обходным решением этой проблемы является установка cron для ssh в локальном окне, чтобы, в свою очередь, запускать команду ssh вместо запуска файла или команды по локальному абсолютному пути. Это кэширует KRB5CCNAME и работает там, где /path /command нет.

# Fails:
0 * * * * /home/user/sshscript.sh

# Works:
0 * * * * /usr/bin/ssh user@localhost /home/user/sshscript.sh

#!/bin/bash
# Works:
unset SSH_AUTH_SOCK
unset KRB5CCNAME
/usr/bin/ssh user@localhost /home/user/sshscript.sh

Answer 3

Вы можете использовать ssh-cron для установки запланированных соединений SSH для защиты серверов, не раскрывая ваши ключи SSH, но используя агент SSH.

Answer 4

Вы можете запустить свой скрипт или команду в crontab, например:

0 * * * * bash -c -l "/home/user/sshscript.sh"

или же

0 * * * * bash -c -l "ssh root @ yourhost 'echo $ HOSTNAME'"