bash: การใช้ scp ในงาน cron ล้มเหลว แต่ทำงานได้สำเร็จเมื่อเรียกใช้จากบรรทัดคำสั่ง

ฉันกำลังพยายามใช้ scp ในสคริปต์ทุบตีที่รันโดย cron (ฉันกำลังใช้งานบน Ubuntu 10.0.4 LTS)

สคริปต์ทำงานได้ดี (เช่นถ่ายโอนและคัดลอก file1 และ file2 ไปยัง / จากเซิร์ฟเวอร์ระยะไกลเมื่อฉันเรียกใช้จากบรรทัดคำสั่งอย่างไรก็ตามเมื่อฉันเรียกใช้สคริปต์เป็นงาน cron มันล้มเหลว

Th คือลักษณะของสคริปต์:

#!/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 (ตามที่แนะนำโดย M Jenkins) ฉันยังเพิ่ม -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).

ฉันเดา:

คุณมีรหัส SSH ที่ป้องกันด้วยรหัสผ่านซึ่งจะถูกโหลดโดยพวงกุญแจ GNOME โดยอัตโนมัติเมื่อคุณลงชื่อเข้าใช้ อย่างไรก็ตาม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 : ไม่มีอุปกรณ์หรือที่อยู่ดังกล่าว

ดูเหมือนว่า scp จะไม่รับคู่กุญแจสาธารณะ / ส่วนตัวของคุณจากไดเรกทอรี ~ / .ssh ของคุณ

ลองเพิ่ม

HOME=/home/oompah

ไปที่ด้านบนของไฟล์ crontab ของคุณ (ควรตั้งค่าไว้โดยอัตโนมัติอยู่แล้ว)

คุณสามารถลองเพิ่มได้

echo "DEBUG: My home dir is $HOME"

ลงในสคริปต์ของคุณเพื่อให้แน่ใจว่าได้รับคุณค่าที่ถูกต้อง

ตัวเลือกอื่นคือการระบุพารามิเตอร์ -i เพื่อ scp เพื่อบังคับให้คู่คีย์เฉพาะใช้:

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

ตัวอย่างเช่น.

cron ผู้ใช้คืออะไร ดูเหมือนว่าผู้ใช้นั้นไม่มีสิทธิ์เข้าถึงกุญแจสาธารณะของคุณ

แม้ว่าจะไม่ใช่ปัญหาในกรณีนี้ cron ตีความเครื่องหมายเปอร์เซ็นต์ ( %) เป็นอักขระขึ้นบรรทัดใหม่ดังนั้นจึงต้องมีการหลบหนี ( \%) หรือคุณจะจบลงด้วยคำสั่งครึ่งหนึ่งที่สงสัยว่าทำไม cron ก็ไม่ทำอะไรเลย (แม้ว่ามันจะบ่น ใน syslog)

สิ่งนี้อาจทำให้เกิดปัญหาได้หากคุณทำงานกับ/bin/datecrontab