一般ユーザーのSSHキーを使用しますが、すべてのコマンド（gitなど）に対するsudoファイル権限を持つ方法

2024-5-29 • tag-icon

files permissions sudo git

一般ユーザーのSSHキーを使用しますが、すべてのコマンド（gitなど）に対するsudoファイル権限を持つ方法

次のようにプロジェクトを複製できます。

$ git clone [email protected]:root/myproject.git ~/bla

しかし、今はそれを複製したいと思います/var/www。

$ git clone [email protected]:root/myproject.git ~/var/www

しかし残念ながら、執筆の権限はありません/var/www。スドが救いに来ます！

$ sudo git clone [email protected]:root/myproject.git ~/var/www
Cloning into 'www'...
[email protected]'s password:

これは何ですか？パスワードの入力を求められますか？臭いパスワードは必要ありません！

明らかに、リクエストとともにrootユーザーのSSHキーを送信していますが、そのキーをgitリポジトリにインポートしていないため、拒否されます。過去に私の解決策は、フォルダの権限を一時的に変更するか、最初にアクセスできる場所に複製してからsudoを使用して移動することでしたが、正しい方法を学びたいと思いました。

それでは...一般的なユーザーのsshキーでsudoファイル権限を使用してgitをどのように使用しますか？

答え1

ssh実行中のエージェントがある場合は、次の操作を行います。

sudo SSH_AUTH_SOCK="$SSH_AUTH_SOCK" git clone...

これは、デフォルトでgitこのコマンドで始まるコマンドroot（またはsshこのコマンドで始まるコマンドgit）にプロキシを使用するように指示します（すべての権限があるため、ssh接続できる必要があります）。root

実行中のSSHエージェントがない場合は、事前に起動できます。

eval "$(ssh-agent)"

（そして必要に応じて追加のキーを使用してくださいssh-add）。

または、次のものを使用できます。

sudo -E git clone...

渡すすべて環境変数sudoは$SSH_AUTH_SOCK。

私はできます。いいえコメントで、@NgOon-Eeが提案したようにリスト$SSH_AUTH_SOCKに追加されましたenv_keep。通常、rootサービスを開始したユーザーは環境を汚染したくありません。たとえばsudo sshd、サービスを開始するとは、そのサービスを介して開始されたすべてのセッションがユーザーエクスペリエンスを継承し、使用できなくなり、使用しないでユーザーエクスペリエンスを汚染することを意味しますsshd。ターゲットユーザーは認証プロキシを使用できないため、ターゲットユーザー以外のターゲットユーザーにもこの変数を渡す必要はありません。ssh$SSH_AUTH_SOCKroot

これで、キー認証の問題のみが解決されます。rootの設定も継承したい場合は、環境変数を使用してこれを行うこと~/.ssh/configはできませんが、ssh可能ですgit。たとえば、sugit関数を次のように定義します。

sugit() {
  sudo "GIT_SSH_COMMAND=
    exec ssh -o IdentityAgent='$SSH_AUTH_SOCK' \
             -o User=$LOGNAME \
             -F ~$LOGNAME/.ssh/config" git "$@"
}

つまり、ルートの代わりにSSHプロファイル、プロキシ、およびユーザー名を使用gitするようにコマンドに指示します。ssh

または、元のユーザーとして実行するように指示することをお勧めしますgit。ssh

sugit() {
  sudo "GIT_SSH_COMMAND=
    exec sudo -Hu $LOGNAME SSH_AUTH_SOCK='$SSH_AUTH_SOCK' ssh" git "$@"
}

答え2

ファイルを実行しているユーザーが重要なファイル（またはソケット）を読み取れない場合、ファイルsudo（またはソケット）の権限が複雑になる可能性があります。これには、rootファイルがroot許可なくネットワーク共有にある場合や、ホームディレクトリが暗号化されてアクセスrootが再び拒否される場合も含まれます。

拡張 ACL をサポートする Unix システムに対する別のアプローチは、拡張 ACL を使用することです。この場合、通常の基本権限に加えて、追加の書き込みアクセス権を付与します。

$ sudo chown apache:www /var/www/html
$ sudo chmod g+s /var/www/html
$ sudo setfacl -m g:webedit:rwx /var/www/html
$ groups
jdoe webedit
$ ls -ld /var/www/html
drwxrwsr-x+ 4 apache www 25 Nov 21 19:42 /var/www/html
$

webeditしかし、グループに権限があるのでsetfacl

$ git clone ~/repo /var/www/html
Cloning into '/var/www/html'...
done.
$ ls -al /var/www/html
total 0
drwxrwsr-x+ 4 apache www   25 Nov 21 19:42 .
drwxr-xr-x  4 root   root  31 Oct 19 20:39 ..
drwxrwsr-x  3 jdoe   www   14 Nov 21 19:42 a
drwxrwsr-x  8 jdoe   www  152 Nov 21 19:42 .git
$

ただし、拡張ACLには、バックアップソフトウェアが拡張ACLをどのように処理するかを確認するなど、さまざまな問題があります。

関連情報