☰

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

tag-icon • tag-icon ssh kubuntu kde gnome-keyring ssh-agent
为什么我无法与 ssh-agent 交互？（例如 ssh-add -D 不起作用）

在我的 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 管理）。

答案1

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

这里解释了启动时发生的情况并找出了罪魁祸首。

使用 KDM（或 LightDM）作为登录管理器，登录后会为您生成一个 X 会话。登录管理器允许您根据系统中可用的会话选择 X 会话（例如 GNOME、KDE ​​Plasma 等）。目录包含已/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=defaultKDE Plasma 桌面中：

⟫ echo $DESKTOP_SESSION
default

这显然是错误的。现在您可以猜出它为什么无法通过白名单检查/etc/upstart-xsessions。

正在运行终端会话的快速修复

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

结论

似乎有人会遇到一个错误，导致所有 Upstart 会话作业根本无法启动。另一个错误会阻止与 GNOME 密钥环 SSH 代理的正确交互（或ssh-add应该会发出警告并失败）。哦，我讨厌你，错误。

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

现在我决定只“使用”Upstart 错误并通过设置来阻止 Upstart 会话作业运行Session=default。我不确定这会造成多大程度的破坏，但到目前为止我还没有看到任何崩溃。

根本原因首先是 GNOME 密钥环的出现，它不应该欺骗我并不断提供错误的密钥。

答案2

我总是sudo apt-get 删除 --purge gnome-keyring无论如何，然后重新启动。ubuntu-sso 依赖它，但我不使用它，所以不用担心。

ssh-agent 似乎之后就可以正常工作了。

答案3

我意识到这是一个老话题。我正在使用 xubuntu 16.04。似乎错误仍然存​​在。我安装了 seahorse 来管理密钥，并且成功了。

答案4

这是一个老问题，但我还是来这里寻找解决方案。

我的发行版中至少存在的一个问题是，如果你使用 GDM（即 Gnome 的显示管理器），它根本不关心 KDE/Plasma，也不会采取任何措施来确保它及其所有配置实用程序能够正确启动。

对于 GDM 您至少要做的事情是确保包含 PAM 相关的设置。

您可以通过两种方式完成此操作。您可以同时安装两者并查看每组配置文件，比较缺少的内容，或者您​​可以尝试我所说的方法。如果情况发生变化，查看配置文件可能是未来最好的选择，但无论哪种方式，情况都应该相似。

您需要编辑的第一个文件是/etc/pam.d/gdm-autologin

在此文件中，你需要在 @include common-session 下添加一行

在 gnome key ring 行下添加此行。

session optional        pam_kwallet5.so auto_start

您需要编辑的下一个文件是/etc/pam.d/gdm-password

在此文件中，你需要添加 1 行@include common-auth

在 gnome key ring.so 行下添加此行。

auth   optional         pam_kwallet5.so

如果您使用 Plasma，这应该可以解决您的登录问题。

您可能只需以其他方式包含这些内容，但这对我在 Ubuntu 22.04 上有效。

希望这可以帮助。

相关内容