リモートサーバー（A）で作業している間は、ローカルSSHキーを使用して制御できない他のサーバー（B）のリポジトリにアクセスしたいと思います。
通常、これは魅力のように動作します。
リモートサーバー（A）にmyUsernameとしてログインし、Bのリポジトリに正常にアクセスできます。
問題は、他のユーザーが（A）で実行する必要があるタスク（作成者の更新）があることです。
ユーザーは管理者ではなく、スクリプトが実行されるフォルダーは自分のものであり、グループ全体ではなくそのユーザーだけを書き込むことができるため、すべてのフォルダーを777、775などにchmodすることはできません。
問題は、スクリプトを実行しようとすると
sudo -u another_user composer update
ユーザーに渡されないため、キーが見つからないことです。
さらに、"another_user"のシェルがbin / falseに設定されており、状況がさらに複雑になりました！
これには回避策がありますか？
要約すると：ローカルSSHキーを使用して、私のリモートサーバーを介して他のリモートサーバーにアクセスしたいと思います。sudo -u another_user ...
より多くの経験を持つ誰かが私に気付くことができれば良いでしょう！
編集する：私も試してみました：http://mybrainhurts.com/blog/2012/05/git-sudo-local-ssh-keys.htmlしかし、他のユーザーはシェルがないので動作しないと思います:(
ベストアンサー1
これを行う唯一の方法は、非常に汚いハッキングを利用することです。私はそれをお勧めしません。
setfacl -R -m u:another_user:rwx "${SSH_AUTH_SOCK%/*}"
sudo -u another_user SSH_AUTH_SOCK="$SSH_AUTH_SOCK" composer update
その理由は、SSHキーが名前付きソケットを介してアクセスされるためです。名前付きソケットはあなたが所有するディレクトリにあり、他の人はアクセスできません。他のユーザーにアクセス権を付与する唯一の方法は、ソケットの権限を変更することです。
上記の方法は、ファイルシステムのプロパティを拡張してこれを実現します。/tmpこれを行う唯一の方法は、ファイルシステムがACLをサポートしていない場合であり、chmod o+rwxこれは非常に安全ではありません。
より良い解決策は、自分のユーザーとしてコマンドを実行するのを妨げる問題を解決することです。