bash:在cron作业中使用scp失败,但是从命令行运行时成功运行


8

我试图在cron运行的bash脚本中使用scp(我在Ubuntu 10.0.4 LTS上运行此脚本)。

该脚本运行良好(例如,当我从命令行运行该脚本时,将文件1和文件2传输到远程服务器并从远程服务器复制文件1和文件2。但是,当我将脚本作为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

为什么会发生,如何解决?

[编辑]

我用-i命令(如M Jenkins的建议)修改了第一个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).

3
如果不将stdout和stderr重定向到/ dev / null,会得到什么输出?
bmk

@bmk:如果没有stdout重定向,我会收到以下消息:权限被拒绝(公钥)。失去连接权限被拒绝(公钥)。
oompahloompah”,2011年

建议:切勿在此类脚本中丢弃stderr。它比仅显示一条“ ERROR”消息更有用。
grawity 2011年

1
可能是a。)在交互式运行命令时使用代理,b。)在没有自己的密钥对(或主文件夹)的情况下以其他用户身份运行该代理,或c。)目标上的authenticated_keys限制了代理的来源连接...?
0xC0000022L

Answers:


7

我猜:

您具有受密码保护的SSH密钥对,登录时GNOME密钥环会自动加载该密钥对。但是,cron它无权访问密钥环,ssh也不能要求输入密码(由于缺少tty)。

引用ssh您添加的日志:

debug1:提供公用密钥:/home/oompah/.ssh/id_rsa
debug1:服务器接受密钥:pkalg ssh-rsa blen 277
debug1:PEM_ read_PrivateKey失败
debug1:读取PEM私钥已完成:输入
debug1:read_passphrase:无法打开/ dev / tty:没有这样的设备或地址


@grawity:感谢您提供信息。我该如何解决该问题?
oompahloompah”,2011年

@oompah:从密钥对中删除密码。(如果需要,您可以创建第二个纯粹用于自动化的应用,并将其提供给scp -i。)
grawity 2011年

@grawity:感谢您的反馈。我不愿意从密钥对中删除密码(无论如何我都不知道该怎么做)。您提到创建一个“第二个”(大概是第二个密钥对),但是这个没有密码,因此我可以将其用于自动登录。顺便说一句,当您说密码时,您的意思是PASSPHRASE吗?
oompahloompah”,2011年

@oompah:如果您的CentOS计算机在物理上是安全的,那就可以了。第二个密钥对建议可能仅在许多系统上都具有主密钥对时才有用。(OpenSSH称其为“密码短语”,但实际上没有多少人使用整个短语作为密钥。)
grawity 2011年

经过大量的钥匙串等工作之后,我终于可以使用它了。最后,我同意了您的建议,为cron创建一个无密码的密钥对,并将其传递给shell脚本中的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 2011年

3

cron以什么用户身份运行?该用户似乎无权访问您的公共密钥。


0

尽管在这种情况下不是问题,但cron会将百分号(%)解释为换行符,因此必须将其转义(\%),否则您将得到半个命令,想知道为什么cron根本不执行任何操作(尽管它会抱怨)在syslog中)。

如果/bin/date在crontab中使用,可能会引起麻烦。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.