ssh代理转发和sudo到另一个用户

如果我有一个服务器A,我可以使用我的ssh密钥login到服务器,并且我可以“sudo su – otheruser”,所以我丢失了密钥转发,因为envvariables被删除并且套接字只能由我原来的用户读取。 有没有一种方法可以通过“sudo su – otheruser”桥接密钥转发,所以我可以使用转发密钥(我的情况下为git clone和rsync)在服务器B上执行一些操作?

我能想到的唯一方法是将我的密钥添加到其他用户的authorized_keys和“ssh otheruser @ localhost”,但是对于我可能拥有的每个用户和服务器组合,这样做很麻烦。

简而言之:

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

    正如你所提到的,出于安全原因,环境variables被sudo删除。

    但是幸运的是, sudo是相当可configuration的:由于/etc/sudoersenv_keepconfiguration选项,您可以准确地确定要保留哪些环境variables。

    对于代理转发,您需要保留SSH_AUTH_SOCK环境variables。 为此,只需编辑/etc/sudoersconfiguration文件(始终使用visudo )并将env_keep选项设置为适当的用户。 如果您希望为所有用户设置此选项,请使用下面的Defaults行:

     Defaults env_keep+=SSH_AUTH_SOCK 

    man sudoers更多的细节。

    你现在应该可以做这样的事情(假设user1的公钥存在于user1@serverAuser2@serverB ~/.ssh/authorized_keys中, 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

    这将为您提供一个仍然加载原始密钥的root shell。

    允许其他用户访问$SSH_AUTH_SOCK文件和它的目录,例如通过正确的ACL,然后切换到它们。 该示例假定主机上/etc/sudoers Defaults:user env_keep += SSH_AUTH_SOCK

     $ 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" 

    尽pipe如此,这是相当危险的。 你基本上是让系统上的其他用户有权使用你的SSH代理(直到你注销)。 您也可以设置组并将权限更改为770,这可能更安全。 但是,当我尝试改变组,我得到了“不允许的操作”。

    如果您有权限sudo su - $USER ,那么您可能会有一个很好的理由,允许您使用ssh -AY $USER@localhost ,并使用您的有效公钥在$ USER的主目录中。 然后,您的身份validation转发将与您一起进行。

    你总是可以通过代理转发ssh到localhost,而不是使用sudo:

     ssh -A otheruser@localhost 

    缺点是您需要重新login,但是如果您在屏幕/ tmux选项卡中使用它,这只是一次性的工作,但是,如果从服务器断开连接,套接字(当然)会再次被破坏。 所以如果你不能保持你的screen / tmux会话始终保持打开状态(不过你可以手动更新你的SSH_AUTH_SOCK env var,如果你很酷的话)。

    还要注意,当使用ssh转发时,root可以随时访问你的套接字并使用你的sshauthentication(只要你使用ssh转发login)。 所以确保你可以信任根。

    不要使用sudo su - USER ,而是使用sudo -i -u USER 。 为我工作!

    不幸的是,当你su给另一个用户(甚至使用sudo),你将失去使用转发的密钥的能力。 这是一个安全function:你不想随机的用户连接到你的SSH代理和使用你的密钥:)

    “ssh -Ay $ {USER} @localhost”方法有点麻烦(正如我对David的回答容易破坏的评论所指出的那样),但这可能是你能做的最好的。

    结合其他答案的信息,我想出了这个:

     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文件。

    testingUbuntu 14.04(不得不安装acl软件包)。

    我觉得你的命令在su后面有- (破折号)选项有问题:

     sudo su - otheruser 

    如果您阅读su的手册页,则可能会发现选项-, -l, --login login以loginshell的forms启动shell环境。 这将为其他用户的环境,而不pipe你运行su的envvariables。

    简而言之,破折号将破坏你从sudo传递的任何东西。

    相反,你应该尝试这个命令:

     sudo -E su otheruser 

    正如@ joao-costa指出的那样, -E将会保留你运行sudo的环境中的所有variables。 那么没有短划线, su会直接使用这个环境。