禁用X11Forwarding是必要的，因其协议不加密、自动注入DISPLAY与xauth凭据，易被中间人劫持或恶意程序利用，导致本地X Server遭键盘监听、屏幕窃取等攻击；须服务端设X11Forwarding no并重启sshd，客户端配ForwardX11 no且清除DISPLAY变量，三者协同方可彻底阻断风险。
为什么禁用 X11Forwarding 是必要的
SSH 默认可能开启 X11Forwarding yes，这会让远程命令（比如 xclock、gedit）的图形界面通过 SSH 隧道回传到本地 X Server 显示。但该机制本身不加密 X11 协议内容（仅加密传输通道），且会自动设置 DISPLAY 和注入 xauth 凭据——一旦 SSH 连接被中间人劫持或终端被恶意程序读取环境变量，攻击者就能直接连上你的本地 X Server，抓窗口、录屏、甚至注入键盘事件。
如何在 sshd 侧彻底关闭 X11 转发
修改服务端 SSH 配置，从源头阻断能力：
- 编辑
/etc/ssh/sshd_config，确保包含这一行（取消注释并设为 no）：X11Forwarding no - 确认没有其他配置文件覆盖它：检查
Include /etc/ssh/sshd_config.d/*.conf下是否有子配置意外启用了X11Forwarding - 重启服务生效：
sudo systemctl restart ssh（或sshd，依发行版而定） - 验证是否生效：执行
sshd -T | grep x11forwarding，输出应为x11forwarding no
客户端连的时候还提示 “Warning: remote host does not support X11 forwarding” 怎么办
这是正常现象，说明服务端已拒绝，但客户端仍尝试协商。要让客户端也默认不发请求：
- 在本地
~/.ssh/config中为对应主机添加：ForwardX11 no - 或者临时连接时加
-o ForwardX11=no参数 - 避免使用
ssh -X或ssh -Y，这两个参数会强制开启 X11 请求，即使服务端拒绝也会触发警告和多余协商
禁用后仍有图形程序意外弹窗？检查 DISPLAY 是否被污染
即使 X11Forwarding 关闭，如果用户手动设置了 DISPLAY（比如 export DISPLAY=:0）或脚本中硬编码了它，本地图形程序仍可能直接连本机 X Server——这不是 SSH 的问题，但容易被误认为“没禁掉”：
- 检查当前 shell 中是否残留
DISPLAY：echo $DISPLAY；若输出非空，且不是localhost:10.0这类 SSH 自动设的值，就可能是手动设置的 - 排查登录脚本（
~/.bashrc、~/.profile）里有没有export DISPLAY=...行 - 某些桌面环境（如 GNOME）可能通过 D-Bus 注入
DISPLAY，需结合loginctl show-session $(loginctl | grep current | awk '{print $1}') -p Type判断是否为 graphical session
真正安全的关键不在“能不能转发”，而在“有没有必要暴露 X Server 给任意进程”。关掉 X11Forwarding 只是第一步；后续若真需要远程 GUI，应该用 VNC、RDP 或容器化 Web UI，而不是依赖 SSH+X11 这种老旧耦合模型。
