场景：
我在本地 PC 上运行 ssh-agent，并且我的所有服务器/客户端都设置为转发 SSH 代理身份验证。我可以使用本地 PC 上的 ssh-agent 在所有机器之间跳转。那个有效。
我需要能够以我自己 (user1) 的身份通过SSH 连接到一台机器，更改为另一个名为 user2 的用户（sudo -i -u user2），然后使用我在本地 PC 上运行的 ssh-agent ssh 到另一个盒子。假设我想做一些类似 ssh user3@machine2 的事情（假设 user3 在其 authorized_keys 文件中有我的公共 SSH 密钥）。
我已将sudo配置为保留SSH_AUTH_SOCK环境变量。
所有涉及的用户（用户 [1-3]）都是非特权用户（不是 root）。
问题：
当我更改为另一个用户时，即使 SSH_AUTH_SOCK 变量设置正确，（假设它设置为：/tmp/ssh-HbKVFL7799/agent.13799）user2 无权访问由 user1 创建的套接字 - 哪个当然是有道理的，否则用户 2 可能会劫持用户 1 的私钥并以该用户身份跳来跳去。
如果我不是通过 sudo 为 user2 获取 shell，而是通过 sudo 为 root 获取 shell，则此场景工作正常。因为 root 自然可以访问机器上的所有文件。
问题：
最好使用 sudo， …
在漏洞大规模发布 24 小时后，Rackspace 对 Spectre 和 Meltdown 保持沉默。他们没有修补所有 Xen 管理程序的计划。他们所有较新的平台服务器都是易受攻击的 HVM 服务器。较旧的 PV 服务器不易受到攻击。
我已经更新了我的 HVM 来宾的 Linux 内核，但 Rackspace 没有更新他们的任何管理程序。在未打补丁的虚拟机管理程序上更新来宾内核会阻止“坏人”虚拟机访问从我打补丁的主机泄漏的内存吗？