X 轉發被中斷，而 ssh 保持連接
從我的主主機[
A]（帶有螢幕），我ssh進入中繼電腦[B]（帶有-X），從那裡我登錄到目標機器[C]（再次帶有-X），X 轉發似乎在一段時間內執行良好。不過，在 vim 中的目標機器[] 上工作了一段時間後，我突然失去了使用 X 轉發功能的能力，我需要從andC註銷，只是為了再次重新啟動 ssh 會話，然後再次正常工作。這發生在正常的一天，即沒有主機掛起（或斷電）。C``B``X當一切按預期工作時，
C顯示：$ echo $DISPLAY localhost:10.0並且類似的應用程序被轉發並在的螢幕上
xeyes呈現良好。A然後突然它會報告：$ xeyes Error: Can't open display: localhost:10.0 $ echo $DISPLAY localhost:10.0並且（都在 上）
/var/log/syslog也沒有暗示任何可疑的東西，ssh 會話再次保持活力和良好。有人知道可能是什麼問題嗎？journalctl``C有關主機的更多詳細資訊：
A是一個物理manjaro盒子（連接到區域網路）B是一個物理的 Ubuntu 21.04 機器（連接到區域網路）C是B執行 Ubuntu 18.04 的虛擬機（通過 NAT 連接）
ForwardX11TrustedDebian 的 man for 中的條目解釋了這一點ssh_config，Ubuntu 的行為與 Debian 相同，但與 Manjaro 不同：
ForwardX11Trusted如果此選項設置為yes，（Debian 特定的預設值），遠端 X11 客戶端將擁有對原始 X11 顯示的完全訪問權限。
如果此選項設置為no（上游預設值），遠端 X11 客戶端將被視為不受信任，並防止竊取或篡改屬於受信任 X11 客戶端的數據。此外， 用於會話的 xauth(1) 令牌將設置為在 20 分鐘後過期。在此時間之後，遠端客戶端將被拒絕訪問。
這可以解釋為什麼如果您主要使用基於 Debian 的系統（如 Ubuntu）之前可能沒有遇到此問題。
啟用此選項的快捷方式是
-Y。因此，您可以在第一個ssh命令中簡單地替換-X為“修復”問題。-Y順便說一句，將X11顯示器轉發兩次並不是最好的方法，尤其是在使用時
-Y，因為如果這是一種多使用者堡壘系統，X11顯示器會在中間系統B中暴露給其他使用者。最好只轉發目標機器 C 的埠 22 並通過它隧道其他所有內容。幸運的是，有一些選項正是為此而設計的：ProxyJump選項及其快捷方式-J。最後，您可以在機器 A 上執行：ssh -Y -J userb@computerB userc@machineC