为什么我不能与我的 ssh-agent 交互？（例如 ssh-add -D 不起作用）

Question

在我的 Kubuntu 14.04 系统上，我试图用我的 SSH 代理管理密钥，但不知何故它似乎忽略了我的ssh-add命令。看看下面这个，你就会明白我的意思。

1. 列出当前键

   ? ssh-add -l
   2048 60:6f:58:ef:7c:b0:ec:94:fb:fa:59:21:86:3d:fc:4c gert@e6230 (RSA)
   

   该密钥在启动时加载，但我期望一些 ECDSA 密钥，而不是 RSA。我不知道这个键...

2. 从代理中删除密钥。

   ? ssh-add -D
   All identities removed.
   

   耶！但是……是吗？

   ? ssh-add -l
   2048 60:6f:58:ef:7c:b0:ec:94:fb:fa:59:21:86:3d:fc:4c gert@e6230 (RSA)
   

   我勒个去？它只是对我说谎。

3. 这里发生了什么？

   ? env | grep -i ssh
   SSH_AUTH_SOCK=/run/user/1000/keyring-eDJggO/ssh
   

   让我们看看哪个进程正在运行该套接字。

   ? sudo fuser -u /run/user/1000/keyring-eDJggO/ssh
   [sudo] password for gert: 
   /run/user/1000/keyring-eDJggO/ssh:  9434(gert)
   ? ps -p 9434 u
   USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
   gert      9434  0.0  0.0 292528  7192 ?        Sl   00:05   0:00 gnome-keyring-daemon [...]
   

   GNOME 钥匙圈到底在我的 KDE 系统上做什么？KDE 钱包不应该是我的 SSH 代理吗？

这导致问题多于答案，我留下了一个非功能性的 ssh 代理。

在另一个系统上，我没有观察到这种行为，也没有发现配置差异。两者都只安装了 KDE，并且安装的软件包几乎相同（由 Puppet 管理）。

Answer 1

注意：不是解决根本问题的答案。如果您认为可以解决根本原因，请提供新答案。你真的必须阅读为什么我的解决方案只是一个丑陋的黑客。

这是对启动时发生的情况的解释，确定了罪魁祸首。

使用 KDM（或 LightDM）作为登录管理器，登录时会为您生成一个 X 会话。登录管理器允许您根据系统中可用的 X 会话（例如 GNOME、KDE ​​Plasma 等）选择一个 X 会话. 该目录/usr/share/xsessions包含安装的每个桌面环境的文件，您的用户特定选择保存在~/.dmrc.

登录后加载桌面环境时，它会加载/etc/X11/Xsession.d/. 在 Kubuntu 14.04 系统上，我看到/etc/X11/Xsession.d/90x11-common_ssh-agent默认情况下正在初始化 SSH 代理。正如预期的那样。伟大的！

然而在实践中，我们看到了不同的东西。那么gnome-keyring-daemon从哪里来，为什么常规ssh-agent没有开始？好吧，GNOME 密钥环以两种方式启动：

• XDG 自动启动，在 /etc/xdg/autostart/gnome-keyring-ssh.desktop
• 作为一个暴发户会议的工作中/usr/share/upstart/sessions/gnome-keyring.conf

所有脚本都首先检查环境值是否会继续。例如

[ -z "$SSH_AUTH_SOCK" ] || [ -z "$GPG_AGENT_INFO" ] || { stop; exit 0; }

这使它成为 SSH 代理实际启动的一种竞争条件。第一个赢。为更多讨厌的东西做好准备。

为什么它在一台机器上可靠地工作而在另一台机器上不可靠？X 会话 upstart 作业仅在DESKTOP_SESSION环境变量在 中被列入白名单时才启动/etc/upstart-xsessions，由 处理/etc/X11/Xsession.d/00upstart。KDM 允许人们有效地设置桌面环境“默认”（default在 中~/.dmrc）kde-plasma，但不会出现kde-plasma。

与Session=kde-plasma：

? echo $DESKTOP_SESSION
kde-plasma

随着Session=default在KDE Plasma桌面：

? echo $DESKTOP_SESSION
default

这是完全错误的。你现在可以猜到为什么它没有通过白名单检查/etc/upstart-xsessions。

运行终端会话的快速修复

killall gnome-keyring-daemon && eval `ssh-agent`

结论

似乎可以在所有 Upstart 会话作业根本没有启动的情况下遇到错误。另一个错误阻止了与 GNOME 密钥环 SSH 代理的正确接口（或者ssh-add应该抱怨并失败）。哦，我讨厌你，臭虫。

一旦我有时间对应该做什么做一些研究，我就会提交错误报告。

现在我决定只“使用”Upstart 错误并通过设置Session=default. 我不确定这破坏了多少，但到目前为止我还没有看到任何东西崩溃。

根本原因首先是 GNOME 密钥环的出现，这不应该对我撒谎并不断提供错误的密钥。