2011-03-31 57 views
2

我有以下bash腳本,它在CLI中運行時沒有問題,但在作爲cron作業運行時失敗。爲什麼這個bash腳本在控制檯上工作,但在作爲cron作業運行時失敗?

#!/bin/bash 

cd /home/oompah/scripts/tests/ 
scp -P 12345 file1 [email protected]:~/uploads 

if scp -P 12345 [email protected]:/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(副本)也失敗了(雖然我沒有檢查它)。有誰知道爲什麼會發生這種情況,以及我如何解決它?

BTW:我在Ubuntu LTS 10.0.4

[編輯]

運行此我添加了-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). 

希望這提供了更多的線索

+0

嘗試chmod 644〜/。服務器上的ssh/authorized_keys – 2011-03-31 17:35:19

回答

0

您可能正在運行ssh-agent或專門授權給您專用密鑰。當您在cron中運行時,您沒有會話,並且您沒有任何與ssh-agentttys等會話一起讀取密碼的任何內容。

創建一個無密碼的密鑰並將公鑰添加到~target/.ssh/authorized_keys下的目標帳戶。然後,您可以使用剛創建的密鑰scp來驗證和複製文件。

僅供參考:您可能需要閱讀關於command keys的ssh服務器手冊頁以及密鑰訪問和身份驗證如何工作。

0

如果不更改用戶帳戶,這將是通常與環境問題。您可以通過運行env和/或設置並將輸出重定向到一個文件來檢查,比較cli和cron的結果。在這種情況下,在運行腳本之前,看起來cron正在執行set -x,因此第一個錯誤會導致腳本退出。

兩種可能的解決方案。添加一個|| true到任何可能失敗而沒有任何問題的命令。或者,您可以在腳本頂部執行set +x以恢復您在命令行上的行爲。


編輯:從頭開始。我雖然你的劇本在第一個scp上死了,直到我重讀你的問題。這很可能是您的環境問題。將env >/path/env.out放在腳本的頂部,並比較您的cli和cron結果。


編輯:另一個想法是,你是否加密主目錄,如果是,你登錄時,這個cron腳本運行?如果您未使用加密目錄登錄,則無法運行該目錄。由於這個原因,我只在桌面上加密主目錄,我將永遠登錄。

+0

如果您的問題是encryptfs,請參閱以下主題:http://ubuntuforums.org/showthread.php?t=1258294 – BMitch 2011-03-31 13:56:10

相關問題