web-dev-qa-db-ja.com

rootでリモートログインが発生した場合、権限がないためにrsyncが失敗するのはどうしてですか？

rsync -e 'ssh -p 19' -vvv /path/to/file [email protected]:を使用した単純なファイルの転送が失敗する理由は考えられません。

opening connection using: ssh -p 19 -l root 192.168.179.3 rsync --server -vvve.Lsfx . .  (11 args)
Permission denied, please try again.
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.1]
[sender] _exit_cleanup(code=12, file=io.c, line=226): about to call exit(12)

ssh login ssh -p 19 [email protected]が正常に機能する場合。成功したローカルファイルのcat [/path/to/file]と権限は664であり、所有者はrsyncを呼び出すユーザーです。ファイルは/tmp/にあります。

-e引数に絶対パスを指定すること、つまりrsync -e '/usr/bin/ssh -p 19' -vvv /path/to/file [email protected]:は役に立ちません。

Ubuntu15.10でrsync3.1.1を使用しています。

linuxsshpermissionsrsync
4
Karl Richter

sshまたはrsyncの別の可能な解釈はPermission denied, please try again.を与えます。その理由は、リモートrsyncが通常とは異なる場所にあり、送信側で--rsync-pathを指定する必要があるためです（ https://stackoverflow.com/questions/7261029/を参照）。 how-to-solve-rsync-error-error-in-rsync-protocol-data-stream-code-12-at-io-c＃comment22193023_12286054 ）。

親愛なるssh開発者、このナンセンスを止めてください！ Permission denied, please try again.をトリガーするエラー原因の数は増加し、増加しています。ユーザーにany使用可能なフィードバックを提供するためにそれを見つけてください-あなたはそうしませんでしたsshを何年も使用し、Permission denied, please try again.で終わる失敗の非常に明確で説明可能な理由に遭遇した後、私が言っているこの方向には何も実装しません。誰もそれを理解できません！

OSがこのメッセージを生成し、変更できないという事実は何の意味もありません。 あなたは、ソフトウェアがユーザーに提供するフィードバックと、上記の失敗の理由を非常に簡単に伝えるためにPermission denied, please try again.が提供されているかどうかを担当します何かが非常に間違っています-代わりにremote binary not found, please use --rsync-path on the sender sideを出力してください！ほら、それほど難しくなかった。

12
Karl Richter

エラーメッセージには、ファイルのアクセス許可については何も書かれていません。むしろ、それは標準のsshエラーメッセージであり、login自体は許可されませんでした–パスワードが間違っているか、サーバー構成がrootによるログインを許可していないためです。

「テスト」とrsyncコマンドの間にはいくつかの違いがあることに注意してください。

  1. Rsyncが[email protected]に接続している間に、sshを[email protected]に接続します。
  2. ポートを指定しないため、標準のSSHポート22に接続しますが、rsyncにはポート19が指定されています。これらのポートは、構成が異なる2つのsshdデーモンによって処理される可能性があります。
1
user1686

他の人に役立つ場合に備えて、ここに私のソリューションを配置します。

Rsyncを使用してファイルをEC2インスタンスにコピーしようとしていました。同じコマンドがしばらくの間正常に機能していましたが、その後機能しなくなりました。私がオンラインで見つけた解決策はどれも本当に役に立ちませんでした。

リモートサーバーにSSH接続し、コピー先の場所でls -lを実行すると、buildフォルダーはrootによって作成され、他のすべてのフォルダーはubuntuによって作成されていることがわかりました。アクセス許可の問題は、ローカルビルドフォルダーをリモートにコピーしようとしたことが原因で発生したため、ローカルビルドフォルダー（とにかくコピーされるべきではなかった）を削除すると、問題が解決しました。

0
Oisín Moran