bash: використання scp у роботі cron не вдається, але працює успішно при запуску з командного рядка


8

Я намагаюся використовувати scp в bash-скрипті, керованому cron (я запускаю це на Ubuntu 10.0.4 LTS).

Сценарій працює чудово (тобто передає та копіює файл1 та 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

Чому це відбувається, і як я можу це виправити ?.

[Редагувати]

Я змінив 1-ю команду 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 я отримую такі повідомлення: У дозволі відмовлено (publickey). втрачено з’єднання Дозвіл відхилено (publickey).
oompahloompah

Пропозиція: ніколи не відкидайте stderr у подібних сценаріях. Це корисніше, ніж мати одне повідомлення "ПОМИЛКА".
користувач1686

1
може бути: a.) ви використовуєте агент під час інтерактивного виконання команди; b) ви запускаєте його як інший користувач без власної пари ключів (або домашньої папки) або c.), що санкціоновані_ ключі в цілі обмежують джерело з'єднання ...?
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 Не вдалося
відладку1: прочитати приватний ключ PEM виконано: введіть
debug1: read_passphrase: не можна відкрити / dev / tty : Немає такого пристрою чи адреси


@grawity: Дякую за інформацію. Як я можу вирішити проблему?
oompahloompah

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

@grawity: Дякую за відгук. Мені не комфортно видаляти пароль із Keypair (я б не знав, як це зробити в будь-якому випадку). Ви згадуєте про створення "другого" - мабуть, ви маєте на увазі друге ключове слово, але це не має пароля - тому я можу використовувати його для автоматизованих входів. До речі, ти маєш на увазі ПАСПСПРАЗУ, коли кажеш пароль?
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 просто нічого не робить (хоча він скаржиться в syslog).

Це може спричинити неприємності, якщо ви працюєте з /bin/dateвашим crontab.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.