X11Forwarding默认值为no，但多数发行版（如CentOS 7/8、Ubuntu 22.04）安装后默认开启；需检查/etc/ssh/sshd_config中非注释的X11Forwarding yes/no行，无输出则实际为no，但建议显式设为no并重启sshd服务。
X11Forwarding 默认是关闭的，但很多发行版（如 CentOS 7/8、Ubuntu 22.04）安装后会默认开启 —— 如果你没手动关过，大概率它开着，这就是风险源头。
确认 X11Forwarding 当前状态
直接查配置比猜更可靠：sshd_config 中这行决定行为：
grep -i "x11forwarding" /etc/ssh/sshd_config
输出可能是 X11Forwarding yes、X11Forwarding no，或完全没这行（此时按 OpenSSH 默认值：no）。注意：注释掉的行（以 # 开头）等同于未设置，不能当作已禁用。
- 若输出为
yes或含yes的非注释行 → 必须改 - 若无输出 → 实际是
no，但建议显式写入，避免未来升级或模板覆盖导致意外开启 - 别只依赖客户端（如 Xshell）关转发 —— 服务端开着，攻击者换工具就能绕过
禁用 X11 转发的正确操作
编辑 /etc/ssh/sshd_config，确保这一行存在且未被注释：
X11Forwarding no
不是 #X11Forwarding no，也不是 X11Forwarding false（OpenSSH 只认 yes/no）。
- 改完必须重启服务：
systemctl restart sshd（CentOS/RHEL）或systemctl restart ssh（Debian/Ubuntu） - 重启后立刻测试：用带 X11 支持的客户端（如 Xshell 或
ssh -X）连接，应不再弹出The remote SSH server rejected X11 forwarding request这类警告 —— 因为服务端根本不再响应 X11 请求 - 如果重启失败，检查
journalctl -u sshd -n 50 --no-pager，常见错误是语法错（比如多空格、拼错单词）或权限问题（sshd_config被设为不可读）
为什么不能只靠客户端禁用？
客户端关 X11（如 Xshell 勾选取消）只是不发起请求，但服务端仍保持监听和处理能力。一旦有其他用户或脚本用 ssh -X 连接，X11 转发就重新激活 —— 安全策略必须落在服务端配置上才可控。
- 攻击者可利用 X11Forwarding +
xauth泄露本地 X server 权限，进而截获键盘输入或伪造窗口 - 即使你不用图形程序，
X11Forwarding yes也会让sshd加载额外模块，增加潜在攻击面 - 合规审计（如等保2.0、CIS Benchmark）明确要求此项设为
no，仅靠客户端设置不满足检查项
顺手清理关联风险项
单独关 X11 不够，它常和其它转发功能共存。检查并统一关闭这些行：
X11Forwarding no<br>TCPForwarding no<br>AllowTcpForwarding no<br>GatewayPorts no
这几项都属于「隧道类能力」，在无业务需求时一并禁用，能显著缩小 SSH 的暴露面。
-
TCPForwarding和AllowTcpForwarding是同一功能的两种写法（后者兼容性更好），保留一个即可 - 改完别忘了
sshd -t测试配置语法是否正确，再systemctl restart sshd - 最容易被忽略的是：改完配置后没验证实际效果 —— 建议用另一台机器执行
ssh -v -X user@host，观察日志里是否出现debug1: Requesting X11 forwarding后立刻被拒绝
