web-dev-qa-db-ja.com

このrsync + ssh cronジョブで「Permission denied（publickey）」エラーが発生するのはなぜですか？

ローカルサーバーに頻繁にバックアップを作成し、それを毎日リモートサーバーに同期します。

ターゲットサーバーは、SSHキー（パスワードなし）アクセス専用に構成されています。そのサーバーのプライマリSSHキーはパスフレーズで保護されているため、 2番目の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を実行しなくなったため混乱していますが、サーバーログには毎分新しいエントリが表示されます。サーバー上のallユーザー（rootを含む）のCrontabファイルは空で、何もしません。

また、ユーザー「バックアップのみ」はサーバー上で作成され、権限が制限され、専用のSSHキーがデスクトップマシンにコピーされました。コマンドを手動で実行するときにすべてが機能するため、これが方法であると想定しています。

上記のcrontabファイルは、デスクトップマシンのユーザー「tom」です。私の意図は、ユーザーに「バックアップのみ」としてサーバーにログインするスクリプトを呼び出すことです。バックアップスクリプト（コマンドを実行するのではなく）を実行してみましたが、正常に接続および動作しました。動作しないcronジョブを作成したユーザー「tom」としてデスクトップ上で実行しました。ログイン成功に対応するサーバーログの出力は次のとおりです。

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
permissionssshbackupcronrsync
19
Tom Brossman

すべてがコマンドラインから正常に機能しているため、エラーPermission denied (publickey)は、rsyncのSSH部分が指定されたユーザー名とは異なるIDファイルを使用していることを意味します。

元の質問の Janのコメント から、-e 'ssh -i /path/to/identity.file' ...を使用してrsyncコマンドでIDファイルを指定できます。

以下のコマンドを使用して、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に関係しています。数日以内に同じシナリオを設定して、テストして報告します。

13
Alaa Ali

私はちょうど私を忙しくしているこの問題を解決しました..

SSHのIDを規定しているにもかかわらず、SSH経由でRSYNCに接続できない...何も実行されない... Rsyncは「許可が拒否されました」と表示され、sshは「read_passphrase：/dev/ttyを開けません：このタイプのデバイスまたはアドレスはありません "

しかし、crontabにはルートとは異なる独自の環境があることを説明した投稿を読みました。私はすでにそれを知っていましたが、SSH-AGENTを使用するときにSSHに与える影響を理解していませんでした

しかし、私のSSH鍵交換はPassPhraseで行われます...したがって、環境が異なり、RSYNC over SSHが入力できないパスフレーズを期待している場合=> 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によって起動されたスクリプトで十分であり、この情報を含むファイルを「ソース」にするか、コマンドラインds crontabで実行します。 ..

例：14 09 * * *。 /home/foo/.keychain/foo.serveur.org-sh && scp -vvv -P 22 /tmp/mon_fic/toto.sh [email protected]：。 >>/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は問題なく機能します。

それは私を忙しくさせていましたが、今では動作します:)

1
SoniXtrA

SSHエージェントフォワーディングを使用する場合の注意事項：

リモートホストでスクリプトをデバッグするときにこの動作が発生する場合、-e "ssh -i /path/to/key"フラグが設定されていても、sshはサーバー上のキーではなくローカル（転送）キーを使用するためです。

具体例：sshを介したrsyncを使用して「データサーバー」からデータをプルするスクリプトをdevサーバーに持っています。 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-idを使用する場合、インストールするキーを-iフラグで指定する必要があります：ssh-copy-id -i ~/.ssh/id_rsa.pub user@Host。

1
jrial

ホストファイルをクリーンアップするという古いトリックをすでに試しましたか？というのは：

rm ~/.ssh/known_hosts

Sshがそれを再構築し、古いものを取り除くので、試してみる価値があります。もちろん、特定のIP /ホストに属するパーツを削除することもできます。

その他の質問：cronジョブはUIDの下で実行されていますか、それともユーザーcronまたはrootとして実行されていますか？

0
runlevel0

この方法でssh部分「ssh -v」に追加してデバッグを試みると、いくつかの有用な情報を含む詳細モードを取得できます。

編集： manページから：

-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.
0
Pedro Luz

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 [email protected]:/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 [email protected]:/ /home/user/servidor

ソース： http://www.guyrutenberg.com/2014/01/14/restricting-ssh-access-to-rsync/

0
Alessandro Cuttin