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

私は私のsshキーを使ってログインすることができますその中に、サーバAを持っていると私が「sudoの秀- otheruser」能力を持っている場合は、ENV変数が削除されているので、私は、キーの転送を失うとソケットは、私の元のユーザーによってのみ読み取り可能です。「sudo su-otheruser」を介してキー転送をブリッジできる方法はありますか。そのため、転送されたキー（私の場合はgit cloneとrsync）を使用してサーバーBで処理を行うことができますか？

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

要するに：

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

前述のように、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_keysにuser1@serverAありuser2@serverB、serverAの/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

sudo -E -s

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

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

他のユーザーが$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$

より安全で、非rootユーザーでも動作します;-)

これも機能することがわかりました。

sudo su -l -c "export SSH_AUTH_SOCK=$SSH_AUTH_SOCK; bash"

他の人が指摘したように、切り替え先のユーザーが$ SSH_AUTH_SOCK（これはルート以外のほとんどのユーザー）に対する読み取り権限を持っていない場合、これは機能しません。これを回避するには、$ SSH_AUTH_SOCKとそれが入っているディレクトリにアクセス権777を設定します。

chmod 777 -R `dirname $SSH_AUTH_SOCK`
sudo su otheruser -l -c "export SSH_AUTH_SOCK=$SSH_AUTH_SOCK; bash"

しかし、これはかなり危険です。基本的に、システム上の他のすべてのユーザーに、SSHエージェントを使用する許可を与えます（ログアウトするまで）。グループを設定し、アクセス許可を770に変更することもできますが、これはより安全です。ただし、グループを変更しようとすると、「操作は許可されていません」と表示されました。

あなたがに許可されている場合sudo su - $USER、あなたはおそらく行うことが許可されているために良い引数だろうssh -AY $USER@localhost$ユーザーのホーム・ディレクトリにあなたの有効な公開鍵を使用して、代わりに。その後、認証の転送が行われます。

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

ssh -A otheruser@localhost

欠点は、再度ログインする必要があることですが、それをscreen / tmuxタブで使用している場合、それは一度だけの努力ですが、サーバーから切断すると、ソケットは（もちろん）再び壊れます。したがって、常にscreen / tmuxセッションを開いたままにできない場合は理想的ではありません（ただし、SSH_AUTH_SOCKクールな場合はenv変数を手動で更新できます）。

また、ssh転送を使用する場合、rootは常にソケットにアクセスし、ssh認証を使用できます（ssh転送でログインしている場合）。そのため、ルートを信頼できることを確認してください。

使用しないsudo su - USERで、むしろsudo -i -u USER。私のために働く！

他の回答からの情報を組み合わせて、私はこれを思いつきました：

user=app
setfacl -m $user:x $(dirname "$SSH_AUTH_SOCK")
setfacl -m $user:rwx "$SSH_AUTH_SOCK"
sudo SSH_AUTH_SOCK="$SSH_AUTH_SOCK" -u $user -i

sudoersファイルを編集する必要がないので、これが気に入っています。

Ubuntu 14.04でテスト済み（aclパッケージをインストールする必要がありました）。

あなたのコマンドの-後の（ダッシュ）オプションに問題があると思いsuます：

sudo su - otheruser

suのマニュアルページを読むと、このオプション-, -l, --loginがシェル環境をログインシェルとして起動することがあります。これは、otheruser実行するenv変数に関係なく環境になりますsu。

簡単に言えば、ダッシュはあなたから渡されたものをすべて損なうでしょうsudo。

代わりに、次のコマンドを試してください：

sudo -E su otheruser

@ joao-costaが指摘したように、-E実行した環境のすべての変数が保存されますsudo。その後、ダッシュなしで、suその環境を直接使用します。

残念ながら、別のユーザーにsu（またはsudoを使用）すると、転送されたキーを使用できなくなります。これはセキュリティ機能です。ランダムなユーザーがssh-agentに接続してキーを使用することは望ましくありません:)

"ssh -Ay $ {USER} @localhost"メソッドは少し面倒です（そして、破損しやすいDavidの回答に関する私のコメントで述べたように）が、おそらくあなたができる最善の方法です。