☰

ssh-agent 転送と別のユーザーへの sudo

tag-icon • tag-icon ssh sudo forwarding ssh-agent agent
ssh-agent 転送と別のユーザーへの sudo

SSHキーでログインできるサーバーAがあり、「sudo su - otheruser」を実行できる場合、環境変数が削除されるため、キー転送が失われます。そしてソケットは元のユーザーのみが読み取り可能です。「sudo su - otheruser」を介してキー転送をブリッジし、転送されたキーを使用してサーバー B で操作 (私の場合は git clone と rsync) できるようにする方法はありますか?

私が考えられる唯一の方法は、otheruser の authorized_keys に自分のキーを追加し、「ssh otheruser@localhost」を追加することですが、これは、私が持つ可能性のあるすべてのユーザーとサーバーの組み合わせに対して実行するのは面倒です。

要するに：

$ sudo -HE ssh user@host
(success)
$ sudo -HE -u otheruser ssh user@host
Permission denied (publickey).

答え1

sudoご指摘のとおり、セキュリティ上の理由から、環境変数は によって削除されます。

しかし幸いなことに、は非常に設定可能です。の設定オプションsudoにより、保持したい環境変数を正確に指定できます。env_keep/etc/sudoers

エージェント転送の場合、環境変数を維持する必要がありますSSH_AUTH_SOCK。これを行うには、/etc/sudoers設定ファイルを編集し (常に を使用visudo)、env_keep適切なユーザーにオプションを設定します。このオプションをすべてのユーザーに設定する場合は、Defaults次のような行を使用します。

Defaults    env_keep+=SSH_AUTH_SOCK

man sudoers詳細については。

これで、次のようなことができるようになります (の公開鍵がとにuser1存在し、のファイルが上記のように設定されていることが条件です)。~/.ssh/authorized_keysuser1@serverAuser2@serverBserverA/etc/sudoers

user1@mymachine> eval `ssh-agent`  # starts ssh-agent
user1@mymachine> ssh-add           # add user1's key to agent (requires pwd)
user1@mymachine> ssh -A serverA    # no pwd required + agent forwarding activated
user1@serverA> sudo su - user2     # sudo keeps agent forwarding active :-)
user2@serverA> ssh serverB         # goto user2@serverB w/o typing pwd again...
user2@serverB>                     # ...because forwarding still works

答え2

sudo -E -s
  • -Eは環境を保護します
  • -sはコマンドを実行します。デフォルトはシェルです。

これにより、元のキーがまだロードされたルート シェルが提供されます。

答え3

許可する他のユーザー$SSH_AUTH_SOCKファイルとそのディレクトリにアクセスするには、たとえば、正しい ACL を使用して、切り替える前にアクセスします。

この例では、「ホスト」マシン上Defaults:user env_keep += SSH_AUTH_SOCKを想定しています:/etc/sudoers

$ ssh -A user@host
user@host$ setfacl -m otheruser:x   $(dirname "$SSH_AUTH_SOCK")
user@host$ setfacl -m otheruser:rwx "$SSH_AUTH_SOCK"
user@host$ sudo su - otheruser
otheruser@host$ ssh server
otheruser@server$

より安全で、非ルートユーザーでも動作します

答え4

sudo を使用する代わりに、エージェント転送を使用して localhost に ssh することもできます。

ssh -A otheruser@localhost

欠点は再度ログインする必要があることですが、screen/tmux タブで使用している場合は、これは 1 回限りの作業です。ただし、サーバーから切断すると、ソケットは (当然) 再び壊れます。したがって、screen/tmux セッションを常に開いたままにできない場合は理想的ではありません (ただし、SSH_AUTH_SOCK問題がなければ env var を手動で更新できます)。

また、SSH 転送を使用する場合、root は常にソケットにアクセスし、SSH 認証を使用できることに注意してください (SSH 転送を使用してログインしている限り)。したがって、root を信頼できることを確認してください。

関連情報