☰

為什麼這個 rsync + ssh cron 作業給我「權限被拒絕（公鑰）」錯誤？

tag-icon • tag-icon permissions ssh backup cron rsync
為什麼這個 rsync + ssh cron 作業給我「權限被拒絕（公鑰）」錯誤？

我經常備份到本機驅動器，並希望每天將其同步到遠端伺服器。

目標伺服器配置為僅用於 SSH 金鑰（無密碼）存取。由於該伺服器的主要 SSH 金鑰受密碼保護，因此我已經創建了第二個 SSH 金鑰（不受密碼保護）+ 用於無人值守備份的用戶- 這樣，當 cron 運行時，我不必在場輸入密碼。

我正在使用 cron 和 rsync，所有命令都單獨工作，但組合時會失敗。

故障排除運行時我能到達的最遠距離

env -i sh -c "rsync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ [email protected]:/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 [email protected]

  4. 在終端機中運行命令效果很好rsync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ [email protected]:/backups/desktop/

  5. 手動指定 backups-user 金鑰的路徑無效rsync -lrstRO --delete --exclude 'lost+found' -e 'ssh -i /home/tom/.ssh/backups-only' /Backups/auto-daily-backups/./ [email protected]:/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/./ [email protected]:/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，但伺服器日誌中每分鐘仍然出現一個新條目。的 crontab 文件全部伺服器上的使用者（包括 root）是空的並且不執行任何操作。

此外，用戶「僅備份」僅在伺服器上創建，權限有限，並將專用 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

答案1

由於命令列一切正常，該錯誤Permission denied (publickey)表示 SSH 部分rsync使用的識別檔案與指定的使用者名稱不同。

從簡的評論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/./ [email protected]:/backups/desktop/"

我仍然對這個發現很感興趣。它可能與 cron （它以最小的環境變數啟動）和 ssh-agent 有關。我將在幾天內設置相同的場景來測試並報告。

答案2

我剛剛解決了這個讓我忙碌的問題..

儘管規定了 SSH 的身份，但無法透過 SSH 在 RSYNC 中連接...什麼也沒做... Rsync 說“權限被拒絕”，ssh 告訴我“read_passphrase：無法打開 /dev/tty：沒有這種類型的設備或位址”

但我讀了一篇文章，解釋 crontab 有自己的環境，與 root 不同。我已經知道這一點，但我不明白使用 SSH-AGENT 時它可能對 SSH 的影響

但我的 SSH 金鑰交換是透過 PassPhrase 完成的...因此，如果環境不同且我的 RSYNC over 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；

==> SSH-AGENT 指令傳回相同的訊息。

因此，最終，正是這些與當前會話相關的資訊允許將來對當前會話進行身份驗證，而無需輸入密碼，因為之前已經完成並記住了...

==> 解決方案就在那裡...在 crontab 啟動的腳本中就足夠了，並且可以「獲取」包含此資訊的檔案或在命令列 ds crontab 上執行此操作...

例如：14 09 * * *。 /home/foo/.keychain/foo.serveur.org-sh && scp -vvv -P 22 /tmp/mon_fic/toto.sh[電子郵件受保護]:. >> /var/log/check_connexion.log 2> & 1 或在使用 SSH 啟動連線的腳本中使用指令「source /home/foo/keychain/foo.server.org-sh」。

=> 有了這個採購，就不用再擔心了。 SSH_AUTH_SOCK 和 SSH_AGENT_PID 的資訊是在 Crontab 環境中載入的，因此已知，RSYNC over SSH 可以正常工作。

它讓我很忙，但現在，它起作用了:)

答案3

使用 SSH 代理轉發的注意事項：

如果您在遠端主機上偵錯腳本時看到此行為，那是因為即使使用該-e "ssh -i /path/to/key"標誌，ssh 也會使用您的本機（轉送）金鑰而不是伺服器上的金鑰。

具體範例：我在開發伺服器上有一個腳本，它使用 rsync 透過 ssh 從「資料伺服器」提取資料。當我登入開發伺服器並運行它時，一切都很好，但是當從 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」）上的使用者名稱與在開發伺服器（“juanr”）上的使用者名稱不同。

Notice how it marks the key on the dev server as "explicit", but still uses the forwarded key from my laptop to log in. Doing an ssh-copy-idat this point resolves nothing, because it simply reinstalls the forwarded key rather than the one from the dev伺服器.如果將 ssh-copy-id 與代理轉發一起使用，則需要使用 -i 標誌指定要安裝的金鑰：ssh-copy-id -i ~/.ssh/id_rsa.pub user@host。

答案4

您是否已經嘗試過清理主機檔案的舊技巧？我是說：

rm ~/.ssh/known_hosts

這是值得嘗試的，因為 ssh 會重建它，並且您將擺脫陳舊的東西。當然，您也可以刪除屬於給定 IP/主機的部分。

更多問題：您的 cron 作業是在您的 UID 下運行還是以 cron 或 root 使用者身分執行？

相關內容