☰

ssh Отказано в доступе только в задании cron

tag-icon • tag-icon bash ssh cron
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былзащищен паролем (с загрузкой keychain ssh-agent), поэтому он не работал из скрипта, но не из сеанса bash. Добавление . ~/.keychain/$HOSTNAME-shв мой скрипт решило проблему (спасибо @grawity, который указал мне правильное направление и дал исчерпывающий ответ).

решение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 (предполагая, что они защищены паролем).

Вы упомянули «Связку ключей» — это программа OS X или скрипт Linux? (Я не очень разбираюсь в архитектуре Mac OS X, но, насколько мне известно, она работает)многосложнее получить доступ к ssh-agent пользователя из cronjob...)

решение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

решение3

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

решение4

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

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

или

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

Связанный контент