このrsync + ssh cronジョブで「Permission denied(publickey)」エラーが表示されるのはなぜですか?


20

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

ターゲットサーバーは、SSHキー(パスワードなし)アクセス専用に構成されています。そのサーバーのプライマリSSHキーはパスフレーズで保護されているため、2番目の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. backups-userキーへのパスを手動で指定しても効果がありません 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これは、1分ごとにローカルでcronを実行しなくなったため混乱していますが、サーバーログに1分ごとに新しいエントリが表示されます。サーバー上のすべてのユーザー(ルートを含む)のCrontabファイルは空で、何もしません。

また、ユーザー「backups-only」はサーバー上で作成され、権限が制限されており、専用の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

3.キーファイルを使用して動作し、6。も動作する場合、...エラー...受信側のsshdログファイルは何を言っていますか?
1

@Jan I getSep 7 14:45:01 <hostname> CRON[18716]: pam_unix(cron:session): session closed for user root
Tom Brossman 14

それは間違ったログ行か、ssh経由で接続しようとしているユーザーがrootです...またはバックアップを開始するマシンからですか?
1

1
トム、念のための2つの質問最初のコメントでは、ログラインにCRON [...]がありますが、次のようになりSep 7 16:06:02 <hostname> sshd[6747]...ます。このログラインがサーバーからのものであり、正しい行であることを100%肯定していますか?投稿したcrontabは、バックアップ専用の crontab です。また、IDファイルを手動で追加してみてくださいrsync .... -e 'ssh -i /home/user/.ssh/identity' ...
1

1
また、auth.log編集2の下に投稿したその行は、サーバーで実行されているcronのためのものであり、ログイン試行とは何の関係もないはずです。tail -f /var/log/auth.logcronを介してスクリプトを実行しようとしているときにサーバーで試すことができますか?また、これが機能するかどうかはわかりませんが、最初のenvコマンドを試して、rsync .... -e 'ssh -vvv -i /home/user/.ssh/identity ...さらにエラーが発生するかどうかを確認できますか?
アラアアリ

回答:


15

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

元の質問に関するJanのコメントから、rsyncコマンドを使用してIDファイルを指定できます-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に関係しています。数日以内に同じシナリオを設定して、テストして報告します。


1
あなたが走ったわけでくださいenv -i sh -c "rsync -lrstRO --delete --exclude 'lost+found' -e 'ssh -i /path/to/identity.file' /Backups/auto-daily-backups/./ backups-only@XX.XX.XX.XX:/backups/desktop/"
qazwsx

@Problemania whops、修正済み。
アラアアリ14

答えがあるようですが、ルートcronである 'sudo crontab -e'を実行しているのか興味があります。「バックアップ」ユーザーとしてログインしているときに「crontab -e」を実行するとどうなりますか。
wlraider70 14年

あなたは質問をした人のためにこれを意味したと思います。しかし、彼はrootではなくユーザー名のcrontabを使用していたため、バックアップユーザーのcrontabは使用したくなかったと思います。
アラアアリ14

ユーザーで同様のスクリプトを実行すると、X11経由でsshキーが取得されるため、キーの場合はローカルコピーが必要であり、このファイルが正しい所有者と権利を持っていることを確認してください。
スヴェレ

1

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

SSHのためのアイデンティティ...何も...行われている規定したにもかかわらず、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 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の環境にロードされているため既知であるため、RSYNC over SSHは問題なく機能します。

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


1

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

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

具体例:sshを介したrsyncを使用して「データサーバー」からデータをプルするスクリプトをdevサーバーに持っています。devサーバーにログインして実行すると問題ありませんが、cronから実行すると許可が拒否されます。SSHプロセスにいくつかの冗長性を追加(flag -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この時点でを実行しても何も解決しません。サーバ。エージェント転送でssh-copy-idを使用する場合、-iフラグでインストールするキーを指定する必要がありますssh-copy-id -i ~/.ssh/id_rsa.pub user@host


0

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

rm ~/.ssh/known_hosts

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

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


1
コマンドはそれぞれ個別に機能するので、削除する~/.ssh/known_hostsとどのように変更されるかわかりませんか?そして、cronは、ユーザーtomにある対応する(パスワードなしの)SSHキーを使用してユーザー「backups-only」としてサーバーにログインすることを意図して、デスクトップ上でユーザー「tom」として実行されます~/.ssh
トムブロスマン

3
@ runlevel0 -rまたは-fフラグは削除する必要known_hostsはありません-これは通常のファイル(ディレクトリではない)であり、読み取り専用ではありません。rm .ssh/known-hosts偶然の間にスペースを追加する-単一文字のタイプミスがあることを考えると、かなり安全になります.し、ssh/known_hostsrm -rf(またはrm -r通常はユーザーのホームフォルダの内容全体を削除します)!
エリアケイガン14

こんにちはエリア、本当に素晴らしいポイント!! 反射アクションとして-rfフラグを使用しますが、絶対に正しいです。私は悪い。
runlevel0 14

0

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/


0

この方法で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.

-1

sshd_configファイルが正しく設定されていないと思います。それを確認しPermitRootLogin yesPubkeyAuthentication yes リモートメンテナンスを行います。


1
彼はrootとしてログインしようとしておらず、おそらく端末からsshを実行し、バックアップコマンドを正常に実行できるため、公開キー認証が正しくセットアップされている可能性があります。
アラアアリ

1
アドバイスをありがとうございますが、私は間違いなくPermitRootLogin有効にしておらず、それを変更する予定はありません。ベストプラクティスは、それを無効にし、通常のユーザーとしてのみssh(必要に応じて「sudoers」に追加)し、rootとしてではないことです。
トムブロスマン14
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.