リモートサーバーでの作業（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しかし、他のユーザーにはシェルがないため、機能しないと思います:(
これを行う唯一の方法は、非常に汚いハックを介することです。私はそれをお勧めしません。
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であり、それはひどく安全ではありません。
より良い解決策は、自分のユーザーとしてそのコマンドを実行することを妨げているものを修正することです。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加