☰

リモートサーバー：cronjobを介してgpgでsshでrsyncを使用すると、権限が拒否されました（公開キー）

tag-icon • tag-icon ssh cron rsync gpg
リモートサーバー：cronjobを介してgpgでsshでrsyncを使用すると、権限が拒否されました（公開キー）

cronjobを介して定期的にリモートVPSをバックアップしたいと思います。どちらのシステムもDebian 10を実行します。私は注意を払ってきました。このガイドそして私の思い通りに調整しました。スクリプトの関連部分：

/root/.local/bin/backup

#!/bin/bash

SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)

rsync -avzAHXh -e ssh root@[someIP]:/path/to/remote/dir /path/to/local/dir \
    || { echo "rsync died with error code $?"; exit 1; }

端末で実行すると、すべてがうまく動作します。しかし、cronjobを介して実行すると、次のようになります。

crontab -u root -e

# m h  dom mon dow   command
  0 6  *    *    *   /root/.local/bin/backup >> /var/log/backup 2>&1

次のように/var/log/backup表示されます。

root@[someIP]: Permission denied (publickey).^M
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(235) [Receiver=3.1.3]
rsync died with error code 12

cronjobには何の問題がありましたか？

PS：ここで動作させるために使用しているgpgキーのパスワードを削除しました。理想的には、パスワードを再追加しても機能する解決策が必要です。

ベストアンサー1

Cronが実行するコマンドには、非常に基本的な実行環境とパス設定があります。よくある間違いは、通常のユーザーIDを使用してコマンドまたはスクリプトをテストすることです。これにより、Cronが実行されると失敗します。

エクスポートされた環境変数はしばしば見落とされます。展開する前に、サブシェルを使用して完全に削除された環境でルートで最終テストを実行するのが賢明です。いつでもその環境をログファイルに印刷するワンタイムcronjobを追加できます。これにより、cronが呼び出されたときにコマンドが実行される正確な条件をシミュレートできます。 2番目の利点は、エラーが発生すると端末に表示され、デバッグが簡単になることです。

スクリプトに割り当てられた変数がエクスポートされていないため、SSHはそれを選択しません。

スクリプトで絶対ファイルパスを使用することも重要です。ディレクトリを特に変更しない限り、特定のディレクトリにあるとは見なされず、ワンタイムテストスクリプトで作業ディレクトリを印刷します。前述の内容も役に立ちます。これに関して、全ての分布が同一であると仮定することはできない。確認してみるのも悪くありません。

おすすめ記事