为什么此rsync + ssh cron作业会给我“权限被拒绝（公钥）”错误？

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

目标服务器仅配置用于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. 用简单的测试命令替换无法正常运行的命令 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文件对我来说是我的台式机上的用户“ tom”。我的意图是让它调用应以“仅备份”用户身份登录到服务器的脚本。我只是尝试运行备份脚本（而不是其中的命令），它成功连接并正常工作。我以用户“ tom”在桌面上运行它，该用户创建了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

由于在命令行中一切正常，该错误Permission denied (publickey)表示的SSH部分rsync使用的身份文件与指定的用户名不同。

从Jan对原始问题的评论中，我们可以使用来在rsync命令中指定身份文件-e 'ssh -i /path/to/identity.file' ...。

使用以下命令从cron中的全新环境开始并指定文件的完整路径显然可以解决此问题：

env -i sh -c "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/"

_{我仍然对这个发现很感兴趣。它可能与cron有关，它以最小的环境变量开头，并且与ssh-agent有关。我将在几天之内设置相同的场景进行测试并报告。}

我刚刚解决了这个使我一直忙..的问题

尽管已经规定了SSH的身份，但仍无法通过SSH在RSYNC中进行连接...未完成... Rsync说“权限被拒绝”，而ssh告诉我“ read_passphrase：无法打开/ dev / tty：没有设备或地址这种类型”

但是我读了一篇文章，解释说crontab有它自己的环境，该环境与root不同。我已经知道了，但是我不了解使用SSH-AGENT可能对SSH产生的影响

但是我的SSH密钥交换是通过PassPhrase完成的...因此，如果环境不同，并且我的SSH上的RSYNC期望无法输入密码，则=> SSH调试信息也会指出错误：

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

在我的机器上，我使用“钥匙串”启动SSH代理，因此不必每次尝试进行远程连接时都重新输入密码。钥匙串会生成一个包含以下信息的文件

SSH_AUTH_SOCK = /tmp/ssh-PWg3yHAARGmP/agent.18891; 导出SSH_AUTH_SOCK; SSH_AGENT_PID = 18893; 导出SSH_AGENT_PID;

==> SSH-AGENT命令返回相同的信息。

因此，最后，正是这些与当前会话有关的信息才允许对当前会话进行将来的身份验证，而无需输入密码，因为之前已经进行过并已存储了该密码...

==>存在解决方案...在crontab启动的脚本中就足够了，并且可以“获取”包含此信息的文件，或者在crontab的命令行ds上执行此操作...

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

=>使用此采购，不再需要担心。SSH_AUTH_SOCK和SSH_AGENT_PID的信息已加载到Crontab的环境中，因此众所周知，SSH上的RSYNC可以正常工作。

它让我很忙，但现在可以了:)

对使用SSH代理转发的用户的警告：

如果在远程主机上调试脚本时看到此行为，那是因为即使带有该-e "ssh -i /path/to/key"标志，ssh也会使用本地（转发）密钥，而不是服务器上的密钥。

具体示例：我在开发服务器上有一个脚本，该脚本使用ssh上的rsync从“数据服务器”中提取数据。当我登录到开发服务器并运行它时，一切都很好，但是从cron运行时，我的权限被拒绝了。-vv我在SSH进程（标志）中添加了一些详细信息：

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”）上与在开发服务器（“ juanr”）上具有不同的用户名。

请注意，它是如何将开发服务器上的密钥标记为“显式”的，但仍使用笔记本电脑中转发的密钥登录。此时，执行任何操作ssh-copy-id都无法解决任何问题，因为它只是重新安装了转发的密钥，而不是重新安装开发人员提供的密钥。服务器。如果在代理转发中使用ssh-copy-id，则需要使用-i标志指定要安装的密钥ssh-copy-id -i ~/.ssh/id_rsa.pub user@host。

您是否已经尝试过清理主机文件的旧技巧？我的意思是：

rm ~/.ssh/known_hosts

值得尝试，因为ssh将对其进行重建，并且您将摆脱陈旧的东西。当然，您也可以删除属于给定IP /主机的部分。

更多问题：您的cron作业是在UID下运行还是以cron或root用户身份运行？

将该rrsync脚本与专用的ssh密钥一起使用，如下所示：

远程服务器

mkdir ~/bin
gunzip /usr/share/doc/rsync/scripts/rrsync.gz -c > ~/bin/rrsync
chmod +x ~/bin/rrsync

本地计算机

ssh-keygen -f ~/.ssh/id_remote_backup -C "Automated remote backup"      #NO passphrase
scp ~/.ssh/id_remote_backup.pub devel@10.10.10.83:/home/devel/.ssh

远程电脑

cat id_remote_backup.pub >> authorized_keys

在新添加的行之前添加以下内容

command="$HOME/bin/rrsync -ro ~/backups/",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding

这样结果看起来像

command="$HOME/bin/rrsync -ro ~/backups/",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAA...vp Automated remote backup

本地

放下crontab以下脚本并x获得许可：

#!/bin/sh
echo ""
echo ""
echo "CRON:" `date`
set -xv
rsync -e "ssh -i $HOME/.ssh/id_remote_backup" -avzP devel@10.10.10.83:/ /home/user/servidor 

资料来源：http : //www.guyrutenberg.com/2014/01/14/restricting-ssh-access-to-rsync/

要尝试调试，请以这种方式将其添加到ssh部分“ ssh -v”中，以获取详细信息。

编辑：从手册页：

-v      Verbose mode.  Causes ssh to print debugging messages about its progress.  This is helpful in debugging connection,
             authentication, and configuration problems.  Multiple -v options increase the verbosity.  The maximum is 3.

我认为您尚未正确配置sshd_config文件。验证PermitRootLogin yes并PubkeyAuthentication yes 进行远程维护。