Почему этот bash-скрипт работает на консоли, но не работает при выполнении задания cron?

Question

У меня есть следующий скрипт bash, который без проблем запускается в CLI, но не запускается при выполнении задания cron.

#!/bin/bash

cd /home/oompah/scripts/tests/
scp -P 12345 file1 oompah@someserver.com:~/uploads

if scp -P 12345 oompah@someserver.com:/path/to/file2.dat local.dat >&/dev/null ; then 
    echo "INFO: transfer OK" ; 
else 
    echo "ERROR: transfer failed" ; 
fi

Сообщение об ошибке, которое я получаю (перенаправляется в файл журнала), когда язапустите его как задание cron:

ERROR: transfer failed

Сообщение об ошибке, которое я получаю в почтовом ящике:

Permission denied (publickey).
lost connection

Первый scp (копия) также не работает (хотя яне проверяя это).Кто-нибудь знает, почему это происходит, и как я могу это исправить?

Кстати: я запускаю это на Ubuntu 10.0.4 LTS

[Редактировать]

Iдобавил опцию -i в scp (первая команда в скрипте), а также добавил отладку (используя опцию v).Вот полная трассировка отладки:

Executing: program /usr/bin/ssh host 12.34.56.78, user oompah, command scp -v -t ~/uploads
OpenSSH_5.3p1 Debian-3ubuntu6, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 12.34.56.78 [12.34.56.78] port 12345.
debug1: Connection established.
debug1: identity file /home/oompah/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3p1 Debian-3ubuntu3
debug1: match: OpenSSH_5.3p1 Debian-3ubuntu3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '[12.34.56.78]:12345' is known and matches the RSA host key.
debug1: Found key in /home/oompah/.ssh/known_hosts:3
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/oompah/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
debug1: read_passphrase: can't open /dev/tty: No such device or address
debug1: No more authentication methods to try.
Permission denied (publickey).
lost connection
Permission denied (publickey).

Надеюсь, это даст больше подсказок

Answer 1

Вы, вероятно, работаете с ssh-agent или специально авторизовали свой закрытый ключ.Когда вы запускаете в cron, у вас нет сеанса, и у вас нет ничего, что бы соответствовало сеансам, таким как ssh-agent или ttys для чтения пароля из.

Создание без пароляключ и добавьте открытый ключ к целевой учетной записи в ~target/.ssh/authorized_keys.Затем вы сможете использовать ключ, который вы только что создали с помощью scp, для авторизации и копирования файла.

К вашему сведению: вы можете прочитать справочную страницу сервера ssh на command keys и узнать, как получить доступ к ключу иработа по аутентификации.

Answer 2

Если вы не меняете учетные записи пользователей, это обычно является проблемой со средой.Вы можете проверить это, запустив env и / или set и перенаправив вывод в файл, сравнив результаты из cli и cron.В этом случае, похоже, что cron делает set -x перед запуском вашего скрипта, поэтому первая ошибка приводит к выходу скрипта.

Два возможных решения.Добавьте || true к любой команде, которая может дать сбой без проблем.Или вы можете сделать set +x в верхней части вашего скрипта, чтобы вернуться к поведению, которое вы используете в командной строке.

---

Редактировать: поцарапайте это.Я думал, что ваш сценарий умирал на первом scp, пока я не перечитал ваш вопрос.Скорее всего, это проблема вашей среды.Поместите env >/path/env.out в верхней части вашего скрипта и сравните свои результаты с клиентом.

---

Редактировать: еще одна идея, шифруете ли вы домашние каталоги, и если да, то вошли ли вы в систему, когда этоскрипт cron запускается?Если вы не вошли в систему с зашифрованным каталогом, вы не сможете его запустить.По этой причине я шифрую только домашние каталоги на рабочих столах, в которые я всегда буду входить.