gpg-agent 神秘地停止工作 - 遠端系統上的代理不再連接到 ssh 套接字
我在本地系統上使用 yubikey nano 在遠端系統上進行加密/解密/簽名，以及 SSH 代理轉發。我記得這是一個熊設置，但它已經完美執行了幾個月。突然斷了。我的搜尋都返回了我在設置時閱讀的相同連結，但我被卡住了。
SSH 代理轉發莫名其妙地起作用。遠端系統顯示：
REMOTE:$ ssh-add -L ssh-rsa blahblah cardno:123我可以從遠端系統使用 SSH 登錄到其他伺服器，它使用 nano 進行身份驗證（我知道這一點，因為它需要觸摸才能啟用代理簽名）。我可以在本地系統的 gpg-agent 日誌中看到有關 SSH 簽名的日誌。
但是，我根本無法讓 GPG 簽名/加密工作。如果我在遠端系統上執行以下命令：
REMOTE:$ echo "$(uname -a)" | gpg2 --armor --clearsign --default-key 0x1234 gpg: all values passed to '--default-key' ignored gpg: no default secret key: No secret key gpg: [stdin]: clearsign failed: No secret key在本地 gpg-agent 日誌中，我沒有看到有關該嘗試的日誌。如果我執行這個命令，我可以在本地 gpg-agent 日誌中看到日誌條目：
REMOTE:$ $ netcat -U /home/user/.gnupg/S.gpg-agent OK Pleased to meet you RESET OK GETINFO PID ERR 67109115 Forbidden <GPG Agent> POOP ERR 67109139 Unknown IPC command <GPG Agent>這會導致本地代理中的這些日誌：
2018-01-05 16:38:32 gpg-agent[865] DBG: chan_10 -> OK Pleased to meet you 2018-01-05 16:38:35 gpg-agent[865] DBG: chan_10 <- RESET 2018-01-05 16:38:35 gpg-agent[865] DBG: chan_10 -> OK 2018-01-05 16:38:45 gpg-agent[865] DBG: chan_10 <- GETINFO PID 2018-01-05 16:38:45 gpg-agent[865] DBG: chan_10 -> ERR 67109115 Forbidden <GPG Agent> 2018-01-05 16:39:01 gpg-agent[865] DBG: chan_10 <- POOP 2018-01-05 16:39:01 gpg-agent[865] DBG: chan_10 -> ERR 67109139 Unknown IPC command <GPG Agent>如果我在遠端系統上的 gpg-connect-agent 上執行 strace -f -F，它似乎連接到 /var/run 中的一個套接字，而不是從 ~/.gnupg/ 中的本地系統轉發的那個。我嘗試刪除兩個套接字，殺死所有 gpg-agent 程序並將 SSH 遠端轉發更改為轉到 /var/run 位置或 ~/.gnupg 位置，但無濟於事。有可能我把這些步驟搞砸了，我會再試一次，但我想知道是否有人知道答案，我想在下次遇到這種情況時有一個容易找到的文章。
本地系統：
Mac OS X 10.11.6 gpg installed with brew gpg (GnuPG) 2.2.1 libgcrypt 1.8.1遠端系統：
ubuntu 17.10 gpg (GnuPG) 2.1.15 libgcrypt 1.7.8編輯：好的，不知道發生了什麼變化，但我將它單獨放置了一會兒，然後回來嘗試再次切換插座，它現在可以工作了：
REMOTE:$ $ echo "$(uname -a)" | strace -f -F gpg2 --armor --clearsign --default-key 0x1234 ... a bunch of garbage ... stat("/run/user/1000/gnupg/S.gpg-agent", {st_mode=S_IFSOCK|0600, st_size=0, ...}) = 0 socket(AF_UNIX, SOCK_STREAM, 0) = 5將我的 SSH 遠端轉發到這個新位置有效。我發誓我之前嘗試過使用 gpgconf –list-dir agent-ssh-socket 提供的套接字路徑，但沒有任何運氣。可能是忘了殺死現有的特工。碰巧，我偶然看到一篇博文報告說這種情況發生了變化： https ://blog.kylemanna.com/linux/gpg-213-ssh-agent-socket-moved/
這裡顯然存在一個間歇性錯誤，或者這是所有這些系統如何相互作用的副作用。我不想涉及太多細節/猜想，但我會考慮以下幾點：
- 第二個 SSH 會話軟管第一個（應該發生嗎？）
- REMOTE 上 SSHD 中的 StreamLocalBindUnlink 未正確獲取管道（可能是因為遠端端的代理仍然打開它們？）
一個很好的解決方法是在 .ssh/config 中使用單獨的特殊主機進行 gpg 代理轉發，並確保只使用一次登錄到該主機名！
它發生的幾次非常令人沮喪，因為管道/執行代理和新 sshd 會話沒有創建新套接字的實例的組合導致了各種混亂（再次可能是由於舊的套接字文件被正在執行的代理保持打開） ）。通常，我沒有時間嘗試解決這樣的問題。
終於在我能夠排除故障和修復的位置遇到了這個問題，我可以可靠地重現問題並展示如何解決它：
工作系統
REMOTE:$ echo "$(uname -a)" | gpg --armor --clearsign --default-key 0x1234 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Linux pooter 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/0lJ/t51agRvvTILdQ2kyDf6wDYFAl9JgSYACgkQdQ2kyDf6 -----END PGP SIGNATURE-----從本地系統執行另一個 SSH 或 Rsync
LOCAL: $ rsync -avze ssh test.txt pooter: bind [127.0.0.1]:5901: Address already in useSCP 不會導致問題，但 RSYNC 顯然會進行 ssh 登錄，因為我看到埠轉發失敗，因為文件複製過來
遠端加密/解密現在失敗
REMOTE:$ echo "$(uname -a)" | gpg --armor --clearsign --default-key 0x1234 gpg: all values passed to '--default-key' ignored gpg: no default secret key: No secret key gpg: [stdin]: clear-sign failed: No secret key修復
- 註銷所有具有套接字轉發的 SSH 會話
- 殺死遠端系統上的所有 gpg 代理
- 驗證 /var/run/xxxx/gnupg 中的管道是否到位
- 如果管道消失，請使用 socket forward 登錄並驗證它們是否被重新創建
對於第 3 步和第 4 步，我已經看到它是雙向的，有時管道仍然存在，有時它們正確地消失了。可能還需要刪除管道文件並重新登錄並確保重新創建它們。
現在一切都應該再次用於加密/解密