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

Возникла очень странная проблема. Я создал небольшой скрипт 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, который указал мне правильное направление и дал исчерпывающий ответ).

Интерактивные команды и задания 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 ...)

Другим обходным решением этой проблемы является установка 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

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

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

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

или

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