我使用 Gnome 3.36.3 (Ubuntu 20.04.1) 和 GnuPG 2.2.19 作为 SSH 代理。
我告诉 OpenSSH 在我的文件中哪里可以找到 GnuPG SSH 代理套接字~/.profile
:
export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)
这在终端窗口中运行良好。每当我连接到远程 SSH 服务器时,系统都会提示我输入 PIN。
但是,当我尝试使用 Nautilus 连接到远程 SFTP 服务器时,我收到错误,要么是一条类似“未授权!”的消息。或者我被要求提供用户名和密码(这当然行不通,因为我只使用密钥)。
作为一种手动解决方法,我发现,pkill gvfsd
在 Nautilus 发出一声抱怨的蜂鸣声后,SFTP 连接将按预期工作。
所以显然重力加速度登录后不知道我的 GnuPG SSH 代理。但稍后会被杀死并重新启动时。
我必须做什么,才能使重力加速度知道我的 GnuPG SSH 代理,无需先手动终止吗?
答案1
总括:
sudo chmod +x /lib/systemd/user-environment-generators/90gpg-agent && reboot
长读:
当使用 Nautilus 打开远程位置时,gvfs-daemon 负责连接到远程系统并在后台安装其文件系统。
gvfs 由 systemd 管理。 systemd 似乎可以独立于您输入的内容来管理自己的环境~/.profile
或~/.bashrc
。
不知何故,在会话后期,即打开 bash 终端窗口时,环境设置~/.profile
可能~/.bashrc
可用于新启动的进程,但不是从一开始就可用。我不太确定这部分是如何工作的,但结果很容易观察到:
如果您在登录后立即查看 gvfs-daemon.service 的环境,您会看到以下内容:
# Get the PID of the running gvfsd
$ FIXME=$(systemctl --user show --property="MainPID" gvfs-daemon.service | grep -o '[0-9]*')
# Show the environment of the running gvfsd
$ tr "\0" "\n" < "/proc/${FIXME}/environ"
您将看到与使用命令的 bash 会话相比,环境要小得多env
:更重要的是,gvfsd 进程环境中没有 SSH_AUTH_SOCK 变量。
如果您现在从 bash 终端重新启动 gvfs 服务并再次查看环境:
$ systemctl --user restart gvfs-daemon.service
$ FIXME=$(systemctl --user show --property="MainPID" gvfs-daemon.service | grep -o '[0-9]*')
$ tr "\0" "\n" < "/proc/${FIXME}/environ"
现在 SSH_AUTH_SOCK 变量已存在,gvfs-daemon 调用的 SFTP 客户端将使用 gpg-agent-socket 作为 SSH 代理,Nautilus 中的远程文件夹将按预期工作。
Debian GnuPG 软件包维护者在哪里意识到这个问题并在以下位置提供了一个 systemd 用户环境生成器脚本
/lib/systemd/user-environment-generators/90gpg-agent
。
然而,该脚本的可执行位未设置,因此可能永远不会启动。
使其可执行并重新启动系统后,SFTP 连接从一开始就按预期打开。
$ sudo chmod +x /lib/systemd/user-environment-generators/90gpg-agent
$ reboot
注意:在研究这个问题时,我多次被误导,因为在系统上工作时环境不断变化。可以肯定的是,请务必重新启动整个系统。只是注销并重新登录 Gnome 会话,显然不会将所有内容重置为与系统启动后相同的状态。