上記の回答を含め、この問題については多くの良い情報があります。しかし、私の場合、私はソース マシンとターゲット マシンの両方の管理者であり、何が起こっているのか、どの「正しい」構成オプションがこの問題を解消するのかを理解したいと考えていました。私は完全に成功したわけではありませんが、他の人がこの情報を役に立つと思うかもしれません.
上記の回答が示すように、対話型シェルを実行している場合、rsync はリモート マシンのパスにある可能性がありますが、ssh で rsync を実行している場合はそうではありません。Siddesh がhttp://siddesh-bg.blogspot.com/2009/02/rsync-command-not-found-error-even.htmlで指摘しているように、これはローカル シェルからリモート rsync へのパスを明示的に指定することで解決できます。 :
rsync -av --rsync-path=/usr/local/bin/rsync -e "ssh -l ssh-user" /source server:/destination
しかし、管理者として、私は問題を回避するだけでなく、問題を解決したいと考えていました。OldSchool は、 https: //groups.google.com/group/comp.unix.solaris/browse_thread/thread/0a06a4d382d752d8?pli=1 に役立つトラブルシューティング アプローチを投稿しました。
彼は、リモートマシンで実行されているシェルを見つけて、そこに確立されている PATH を見つけることを提案しています。
ssh user@host 'echo $SHELL'
ssh user@host 'echo $PATH'
Tom Feiner はWhy does an SSH remote command get less environment variables then when run manually? に素敵な投稿をしています。SSHコマンド実行シェルの環境構築について解説しています。
OldSchool はまた、「man sshd_config」が ssh セッションが環境を取得する方法に関する情報を提供することにも言及しました。sshd_config 設定 "PermitUserEnvironment" を設定して、サーバー側のユーザーの ~/.ssh/environment と AuthorizedKeysFile ファイルの環境オプションを sshd で処理できるようにすることができます。デフォルトはいいえです。
したがって、デフォルトの sshd_config 設定では、パスはデフォルトのシェルによって構築されます。ssh コマンドが対話型セッション (ssh user@host) を要求する場合、リモート サーバー上でデフォルト シェルが対話型ログインを実行し、おそらく期待どおりの PATH になります。ただし、rsync の ssh セッションを開始している場合 (rsync -av --rsync-path=/usr/local/bin/rsync -e "ssh -l ssh-user" /source server:/destination)、リモート サーバーは非対話型シェルである SSH コマンド実行シェル。私の場合、リモートの非対話型シェル (bash) は /etc/profile を実行していません。これは、対話型シェルまたは --login オプションを使用した非対話型シェルに対してのみ実行するためです。次のように強制できます。
ssh user@host 'echo $PATH;source /etc/profile;echo $PATH'
また、Daniel Barrett と Richard Silverman の「SSH The Secure Shell」(O'Reilly 2001) を研究し、/etc/ssh/sshrc に PATH を設定して、SSH コマンド実行シェルで rsync を使用できるようにしたかったのですが、/etc/ssh /sshrc ユーザーのシェルまたはコマンドが呼び出される前に実行され、明らかにその環境はそのシェルまたはコマンドに渡されません。
この時点で、rsync コマンド ライン オプションに満足しています。つまり、次のようになります。
rsync -av --rsync-path=/usr/local/bin/rsync -e "ssh -l ssh-user" /source server:/destination
sshd_config 設定の「PermitUserEnvironment」を変更すると、サーバーのセキュリティ監査に失敗する可能性が高いのではないかと心配しているからです。私たちの組織のセキュリティ監査でより多くの経験を積んだ後、私はこれを再検討するかもしれません.