bash: использование scp в cron не удается, но запускается успешно при запуске из командной строки


8

Я пытаюсь использовать scp в скрипте bash, запущенном cron (я запускаю это на Ubuntu 10.0.4 LTS).

Скрипт работает нормально (т.е. передает и копирует file1 и file2 на / с удаленного сервера, когда я запускаю его из командной строки. Однако, когда я запускаю скрипт как задание 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 с помощью команды -i (как предложено М. Дженкинсом), а также добавил -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).

3
Какой вывод вы получите, если не перенаправите stdout и stderr в / dev / null?
— BMK

@bmk: без перенаправления stdout я получаю следующие сообщения: Permission denied (publickey). потерянное соединение Отказано в доступе (publickey).
— oompahloompah

Предложение: никогда не отказывайтесь от stderr в таких скриптах. Это более полезно, чем иметь одно сообщение «ОШИБКА».
— user1686

1
может быть так, что: а) вы используете агент при интерактивном запуске команды, б) вы запускаете его как другого пользователя без собственной пары ключей (или домашней папки) или в.), что авторизованные_ключи на цели ограничивают источник связь ...?
— 0xC0000022L

Ответы:


7

Мое предположение:

У вас есть защищенная паролем пара ключей SSH, которая автоматически загружается в GNOME Keyring при входе в систему. Однако cronон не имеет доступа к связке ключей и sshне может запрашивать пароль (из-за отсутствия tty).

Чтобы процитировать sshдобавленный вами журнал:

debug1: предложение открытого ключа : /home/oompah/.ssh/id_rsa
debug1: сервер принимает ключ: pkalg ssh-rsa blen 277
debug1: ошибка PEM_
read_PrivateKey debug1: чтение закрытого ключа PEM выполнено: введите
debug1: read_passphrase: не удается открыть / dev / tty : нет такого устройства или адреса


@ Grawity: Спасибо за информацию. Как мне решить проблему?
— oompahloompah

@oompah: удалите пароль из пары ключей. (Если вы хотите, вы можете создать второй исключительно для автоматического использования и передать его scp -i.)
— user1686

@ Grawity: Спасибо за отзыв. Мне неудобно удалять пароль из моей пары ключей (я не знаю, как это сделать в любом случае). Вы упоминаете о создании «второй» - вероятно, вы имеете в виду вторую пару ключей - но это без пароля - так что я могу использовать его для автоматического входа. Кстати, вы имеете в виду PASSPHRASE, когда вы говорите пароль?
— oompahloompah

@oompah: Если ваша машина CentOS физически защищена, все в порядке. Второе предложение пары ключей, вероятно, будет полезно только в том случае, если у вас есть основная пара ключей во многих системах. (OpenSSH называет это «парольной фразой», но на самом деле не многие люди используют целую фразу для своих ключей.)
— user1686

Я, наконец, заставил это сработать, после долгих разговоров с цепочкой для ключей и т. Д. В конце концов, я согласился предложить вам создать пару ключей без пароля для cron и передать ее scp в сценарии оболочки. Это не должно быть так сложно на самом деле ... SMH
— oompahloompah

3

Похоже, что scp не берет вашу пару открытых / закрытых ключей из вашей директории ~ / .ssh.

Попробуйте добавить

HOME=/home/oompah

в верхнюю часть вашего файла crontab (он должен быть установлен в любом случае автоматически)

Вы также можете попробовать добавить

echo "DEBUG: My home dir is $HOME"

в ваш сценарий, чтобы убедиться, что он получает правильное значение.

Другой вариант - указать параметр -i для scp, чтобы принудительно использовать определенную пару ключей:

scp -i /home/oompah/.ssh/id_rsa ...

например.


Я попробовал ваше предложение (используя опцию -i). Пожалуйста, смотрите мой обновленный вопрос
— oompahloompah

3

От какого пользователя работает cron? Похоже, у этого пользователя нет доступа к вашему открытому ключу.


0

Хотя в данном случае это не проблема, cron интерпретирует знак процента ( %) как символ новой строки, поэтому его необходимо экранировать ( \%), иначе вы получите половину команды, которая задается вопросом, почему cron просто ничего не делает (хотя он будет жаловаться в системном журнале).

Это может вызвать проблемы, если вы работаете /bin/dateв crontab.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.