为什么这个bash脚本在控制台工作,但作为cron作业运行时失败?

我有以下bash脚本,它在CLI中运行时没有问题,但在作为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作业运行时得到的错误消息(redirect到一个日志文件)是:

 ERROR: transfer failed 

我在邮件收件箱中收到的错误消息是:

 Permission denied (publickey). lost connection 

第一个SCP(复制)也失败了(虽然我没有检查它)。 有谁知道为什么会发生这种情况,以及我如何解决这个问题?

顺便说一句:我在Ubuntu 10.0.4 LTS上运行这个

[编辑]

我将-i选项添加到scp(脚本中的第一个命令),并添加了debugging(使用v选项)。 这是完整的debugging跟踪:

 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-agent或专门授权给您的私钥。 当你在cron运行时你没有会话,而且你没有任何与ssh-agentttys等会话一起读取密码的事情。

创建一个无密码的密钥,并将公钥添加到~target/.ssh/authorized_keys下的目标帐户。 然后,您将能够使用刚创建的密钥与scp来验证和复制文件。

仅供参考:您可能需要阅读command keys上的ssh服务器手册页以及密钥访问和身份验证的工作方式。

如果您不更改用户帐户,这通常会成为环境问题。 您可以通过运行env和/或设置并将输出重定向到一个文件来检查,比较cli和cron的结果。 在这种情况下,看起来在运行脚本之前,cron正在执行set -x ,所以第一个错误会导致脚本退出。

两种可能的解决 添加一个|| true 对任何可能失败而没有任何问题的命令都是|| true 。 或者,您可以在脚本顶部set +x来恢复您在命令行上的行为。


编辑:从头开始。 我虽然你的剧本是死在第一个SCP,直到我重读你的问题。 这很可能是你的环境问题。 将env >/path/env.out放在脚本的顶部,比较你的cli和cron的结果。


编辑:另一个想法,你是加密主目录,如果是这样,你是否登录时,这个cron脚本运行? 如果你没有用加密的目录登录,你将无法运行这个。 出于这个原因,我只加密桌面上的主目录,我将永远登录。