ssh-agent转发和sudo到另一个用户

如果我拥有可以使用ssh密钥登录到的服务器A，并且具有“ sudo su-otheruser”的能力，则将丢失密钥转发，因为已删除了env变量，并且套接字只能由原始用户读取。有没有办法可以通过“ sudo su-otheruser”桥接密钥转发，以便可以使用转发的密钥（在本例中为git clone和rsync）在服务器B上做一些事情？

我能想到的唯一方法是将我的密钥添加到otheruser和“ 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运行命令，默认为shell

这将为您提供一个根shell，且原始密钥仍处于加载状态。

在切换到其他用户之前，例如通过正确的ACL，允许其他用户访问$SSH_AUTH_SOCK文件及其目录。该示例假定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的读取权限（除root外，几乎所有用户）都无法使用。您可以通过设置$ 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使用$ USER的主目录中的有效公共密钥来进行替代。然后，您的身份验证转发将随身进行。

您始终可以通过代理转发将ssh转到localhost，而不是使用sudo：

ssh -A otheruser@localhost

缺点是您需要再次登录，但是如果您在屏幕/ tmux选项卡中使用它，那只是一次工作，但是，如果断开与服务器的连接，套接字（当然）将再次断开。因此，如果您无法始终保持屏幕/ tmux会话始终处于打开状态（这很不理想）（但是，SSH_AUTH_SOCK如果您很酷，可以手动更新环境变量）。

另请注意，在使用ssh转发时，root用户始终可以访问您的套接字并使用ssh身份验证（只要您使用ssh转发登录即可）。因此，请确保您可以信任root。

不要用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以登录shell身份启动shell环境。otheruser无论您在何处运行env变量，都将为环境提供支持su。

简而言之，破折号会破坏您从中传递的任何东西sudo。

相反，您应该尝试使用以下命令：

sudo -E su otheruser

正如@ joao-costa指出的那样，-E它将在您运行的环境中保留所有变量sudo。然后没有破折号，su将直接使用该环境。

不幸的是，当您向另一个用户求助（甚至使用sudo）时，您将失去使用转发密钥的能力。这是一项安全功能：您不希望随机用户连接到ssh-agent并使用密钥：）

“ ssh -Ay $ {USER} @localhost”方法有点麻烦（并且正如我对David的答案容易破损的评论所指出的那样），但这可能是您可以做到的最好的方法。