为什么这个rsync + ssh cron作业会给我“拒绝权限(公开密钥)”错误？

Question

我经常备份到本地驱动器，我想每天同步到远程服务器。

目标服务器配置为仅用于SSH密钥(没有密码)访问。由于该服务器的主SSH密钥是密码(受保护的)，所以我有创建了第二个SSH密钥(没有密码保护)+用户，用于无人值守的备份 -这样在cron运行时，我不需要出现就可以输入我的密码。

我使用cron和rsync，所有命令都单独工作，但合并后失败。

在故障排除过程中，我所得到的最远的

env -i sh -c "rsync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ backups-only@XX.XX.XX.XX:/backups/desktop/"

返回错误的

Permission denied (publickey).
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(226) [sender=3.1.0]

关于如何进一步排除此问题的提示吗？

到目前为止，我已经尝试过了，但我没有任何想法：

1. Cron绝对在运行ps aux | grep cron
2. 在/var/log/syslog Sep 7 13:22:01 desktop CRON[6735]: (tom) CMD (sh /home/tom/Documents/Scripts/offsite-backup)中没有什么异常
3. 终端到远程服务器中的SSH作为备份用户工作ssh backups-user@XX.XX.XX.XX
4. 在终端中运行命令可以很好地运行rsync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ backups-only@XX.XX.XX.XX:/backups/desktop/
5. 手动指定备份的路径-用户键对rsync -lrstRO --delete --exclude 'lost+found' -e 'ssh -i /home/tom/.ssh/backups-only' /Backups/auto-daily-backups/./ backups-only@XX.XX.XX.XX:/backups/desktop/没有影响。
6. 用简单的测试命令works echo "Hello world" > ~/Desktop/test.txt替换非功能命令。
7. 对着电脑大喊大叫/咒骂没有任何效果(但使我暂时感觉好些了)。

编辑1:

这是我的crontab文件和它调用的脚本。

...
# m h  dom mon dow   command
MAILTO=""
* * * * * sh /home/tom/Documents/Scripts/offsite-backup

和

#!/bin/bash

rsync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ backups-only@XX.XX.XX.XX:/backups/desktop/

编辑2:

澄清一下，目标服务器上的/var/log/auth.log包含行Sep 11 08:23:01 <hostname> CRON[24421]: pam_unix(cron:session): session closed for user root --这让人困惑，因为我不再在本地每分钟运行cron，但是在服务器日志中仍然每分钟都会出现一个新条目。服务器上所有用户(包括root用户)的Crontab文件都是空的&什么都不做。

此外，用户“只备份”仅在服务器上创建，权限有限，并将专用SSH密钥复制到我的桌面计算机上。我认为这是可行的，因为在手动运行命令时，一切都可以正常工作。

上面发布的crontab文件是给我的，用户“汤姆”在我的桌面机器上。我的意图是让它调用脚本，该脚本应该作为用户‘只备份’登录到服务器。我只是试着运行备份脚本(而不是其中的命令)，它成功地连接并工作了。我以用户“汤姆”的身份在我的桌面上运行它，也就是创建无法工作的cron作业的用户。以下是与成功登录相对应的服务器日志的输出

Sep 11 08:35:31 <hostname> sshd[25071]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
Sep 11 08:35:32 <hostname> sshd[25071]: Accepted publickey for backups-only from <desktop IP> port 54242 ssh2: RSA e2:e6:07:27:c1:continues...
Sep 11 08:35:32 <hostname> sshd[25071]: pam_unix(sshd:session): session opened for user backups-only by (uid=0)
Sep 11 08:35:32 <hostname> systemd-logind[638]: New session 12 of user backups-only.
Sep 11 08:36:00 <hostname> sshd[25133]: Received disconnect from <desktop IP>: 11: disconnected by user
Sep 11 08:36:00 <hostname> sshd[25071]: pam_unix(sshd:session): session closed for user backups-only

Answer 1

我刚刚解决了这个一直让我忙的问题。

无法通过SSH连接RSYNC，尽管已规定了SSH ...Nothing的标识，但仍在执行.Rsync说“权限被拒绝”，ssh告诉我"read_passphrase:无法打开/dev/tty:没有这种类型的设备或地址“

但我读到了一篇文章，其中解释了crontab有自己的环境，而这个环境与root不一样。我已经知道了，但是我不明白当使用SSH代理时它会对SSH产生什么影响。

但是我的SSH密钥交换是用PassPhrase完成的..。因此，如果环境是不同的，并且我的RSYNC在SSH上需要一个不能输入的密码，=> SSH调试信息也表明了错误：

"debug1: read_passphrase:无法打开/dev/ TTY :没有这样的设备或地址“=>，好的，没有TTY=不允许密码

在我的机器上，我使用"Keychain“来启动SSH代理，这样我就不必每次尝试远程连接时都重新输入密码。Keychain生成一个包含以下信息的文件

SSH_AUTH_SOCK = /tmp/ssh-PWg3yHAARGmP/agent.18891；出口SSH_AUTH_SOCK；SSH_AGENT_PID = 18893；出口SSH_AGENT_PID；

==> -代理命令返回相同的信息。

因此，最后，正是这些与当前会话相关的信息允许对当前会话进行将来的身份验证，而无需输入密码，因为之前已经完成并记住了.

==>解决方案在那里..。它在crontab启动的脚本中就足够了，并且可以“源”包含这些信息的文件，或者在命令行ds ( crontab )上这样做.

例子: 14 09 * **。/home/foo/..keychain/foo.serveur.org-sh& scp -vvv -P 22 /tmp/mon_fic/to.sh foo@my-server.fr：。>> / var / log / check_connexion.log 2> &1或在使用SSH启动连接的脚本中使用命令"source /home/foo/keychain/foo.server.org-sh“。

=>有了这个资源，就不用担心了。SSH_AUTH_SOCK和SSH_AGENT_PID的信息是在Crontab的环境中加载的，因此我们知道，SSH上的RSYNC工作没有任何问题。

它一直让我很忙，但现在，它起作用了:)

Answer 2

请注意使用SSH代理转发的用户：

如果在远程主机上调试脚本时看到这种行为，这是因为即使使用-e "ssh -i /path/to/key"标志，ssh也将使用本地(转发)键而不是服务器上的键。

具体示例:我在dev服务器上有一个脚本，它使用ssh上的rsync从“数据服务器”获取数据。当我登录到dev服务器并运行它时，一切正常，但是当从cron运行时，我被拒绝了权限。在SSH进程中添加一些详细内容(标志-vv)，我注意到以下内容：

debug2: key: /home/nighty/.ssh/id_rsa (0x562d8b974820),
debug2: key: /home/juanr/.ssh/id_rsa (0x562d8b962930), explicit
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/nighty/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp 1a:19:08:9f:80:16:b1:db:55:42:9a:52:b2:49:9b:0a
debug1: Authentication succeeded (publickey).

这里告诉我的是，纯属偶然，我碰巧在本地主机("nighty")上有一个与dev服务器("juanr")不同的用户名。

请注意，它如何将dev服务器上的键标记为“显式”，但仍然使用我的膝上型计算机上的转发密钥进行登录。此时执行ssh-copy-id不会解决任何问题，因为它只是恢复转发的密钥，而不是从dev服务器恢复密钥。如果在代理转发中使用ssh-copy，则需要指定使用-i标志：ssh-copy-id -i ~/.ssh/id_rsa.pub user@host安装哪个键。

Answer 3

你已经尝试过清理主机文件的老把戏了吗？我是说：

rm ~/.ssh/known_hosts

值得一试，因为ssh将重建它，您将摆脱陈腐的东西。当然，您也可以删除属于给定IP /主机的部分。

更多问题:您的cron作业是在您的UID下运行，还是作为用户cron或root运行？