bash: sử dụng scp trong cron job không thành công, nhưng chạy thành công khi chạy từ dòng lệnh


8

Tôi đang cố gắng sử dụng scp trong tập lệnh bash được chạy bởi cron (Tôi đang chạy chương trình này trên Ubuntu 10.0.4 LTS).

Kịch bản hoạt động tốt (tức là chuyển và sao chép tệp1 và tệp2 sang / từ máy chủ từ xa, khi tôi chạy nó từ dòng lệnh. Tuy nhiên, khi tôi chạy tập lệnh dưới dạng công việc định kỳ thì không thành công.

Đó là những gì kịch bản trông giống như:

#!/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

Thông báo lỗi tôi nhận được (chuyển hướng đến tệp nhật ký) khi tôi chạy nó dưới dạng công việc định kỳ là:

ERROR: transfer failed

Thông báo lỗi tôi nhận được gửi đến hộp thư đến của mình là:

Permission denied (publickey).
lost connection

Tại sao lại xảy ra, và làm thế nào tôi có thể sửa nó?.

[Biên tập]

Tôi đã sửa đổi lệnh scp thứ nhất bằng lệnh -i (theo đề xuất của M Jenkins), tôi cũng đã thêm -v cho các thông báo gỡ lỗi. Dưới đây là nhật ký thông báo gỡ lỗi đầy đủ. Hy vọng, nó có thể làm sáng tỏ những gì đang diễn ra:

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
Bạn nhận được kết quả đầu ra nào nếu bạn không chuyển hướng thiết bị xuất chuẩn và thiết bị xuất chuẩn sang / dev / null?
bmk

@bmk: không có chuyển hướng xuất sắc, tôi nhận được các thông báo sau: Quyền bị từ chối (khóa công khai). mất kết nối Quyền bị từ chối (khóa công khai).
oompahloompah

Gợi ý: Đừng bao giờ loại bỏ stderr trong các tập lệnh như thế này. Nó hữu ích hơn là có một thông báo "LRI".
dùng1686

1
có thể là a.) bạn sử dụng một tác nhân khi tương tác chạy lệnh, b.) bạn chạy nó như một người dùng khác mà không có cặp khóa riêng (hoặc thư mục chính) hoặc c.) mà ủy quyền_key trên mục tiêu hạn chế nguồn của kết nối ...?
0xC0000022L

Câu trả lời:


7

Tôi đoán:

Bạn có một cặp khóa SSH được bảo vệ bằng mật khẩu, được tự động tải bởi Khóa Gnome khi bạn đăng nhập. Tuy nhiên, cronkhông có quyền truy cập vào khóa và sshcũng không thể yêu cầu mật khẩu (do thiếu tty).

Để trích dẫn sshnhật ký bạn đã thêm:

debug1: Cung cấp khóa công khai : /home/oompah/.ssh/id_rsa
debug1: Server chấp nhận chìa khóa: pkalg ssh-rsa blen 277
debug1: PEM_ read_PrivateKey thất bại
debug1: đọc PEM khóa bí mật thực hiện: Loại
debug1: read_passphrase: không thể mở / dev / tty : Không có thiết bị hoặc địa chỉ như vậy


@grawity: Cảm ơn thông tin. Làm thế nào để tôi khắc phục vấn đề mặc dù?
oompahloompah

@oompah: Xóa mật khẩu khỏi cặp khóa của bạn. (Nếu bạn muốn, bạn có thể tạo một cái thứ hai hoàn toàn để sử dụng tự động và cung cấp cho nó scp -i.)
user1686

@grawity: Cảm ơn đã phản hồi. Tôi không thoải mái khi xóa mật khẩu khỏi Khóa của mình (Tôi sẽ không biết làm thế nào để làm điều đó trong mọi trường hợp). Bạn đề cập đến việc tạo "cái thứ hai" - có lẽ bạn có nghĩa là một khóa thứ hai - nhưng cái này không có mật khẩu - vì vậy tôi có thể sử dụng nó để đăng nhập tự động. BTW, bạn có nghĩa là PASSPHRASE khi bạn nói mật khẩu?
oompahloompah

@oompah: Nếu máy CentOS của bạn an toàn về mặt vật lý thì không sao. Gợi ý khóa phím thứ hai có lẽ sẽ chỉ hữu ích nếu bạn có cặp khóa chính trên nhiều hệ thống. (OpenSSH gọi đó là "cụm mật khẩu", nhưng thực tế không có nhiều người sử dụng toàn bộ cụm từ cho các khóa của họ.)
user1686

Cuối cùng tôi cũng đã làm được việc này, sau rất nhiều lần vặn vẹo với móc khóa, v.v ... Cuối cùng, tôi đã giải quyết cho bạn đề nghị tạo một khóa không mật khẩu cho cron và chuyển nó vào scp trong kịch bản shell. Không cần phải quá khó khăn như vậy ... SMH
oompahloompah

3

Có vẻ như scp không chọn cặp khóa công khai / riêng tư từ thư mục ~ / .ssh của bạn.

Hãy thử thêm

HOME=/home/oompah

vào đầu tệp crontab của bạn (dù sao nó cũng phải được đặt tự động)

Bạn cũng có thể thử thêm

echo "DEBUG: My home dir is $HOME"

vào tập lệnh của bạn để đảm bảo rằng nó nhận được giá trị đúng.

Một tùy chọn khác là chỉ định tham số -i cho scp để buộc một cặp khóa cụ thể sử dụng:

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

ví dụ.


Tôi đã thử đề xuất của bạn (sử dụng tùy chọn -i). Vui lòng xem câu hỏi cập nhật của tôi
oompahloompah

3

Những gì người dùng là cron chạy như? Có vẻ như người dùng đó không có quyền truy cập vào khóa công khai của bạn.


0

Mặc dù không phải là vấn đề trong trường hợp này, cron diễn giải ký hiệu phần trăm ( %) là ký tự dòng mới, vì vậy nó phải được thoát ( \%) hoặc bạn sẽ kết thúc bằng một nửa lệnh tự hỏi tại sao cron đơn giản không làm gì (mặc dù nó sẽ phàn nàn trong syslog).

Điều này có thể gây rắc rối nếu bạn đang làm việc với /bin/datecrontab của bạn.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.