Ubuntu XRDP root远程桌面排查记录

[TOC]

1、问题背景

这篇文章记录一次 Ubuntu 服务器 XRDP 远程桌面排查过程。故障发生在 2026-03-17，最终验证有效的方案并不是升级 XRDP，也不是强行把 root 用户切到其他桌面环境，而是把 XRDP 相关配置恢复到之前已经跑通过的状态。

这次排查中有一个很关键的结论：root 用户图形化远程登录，本身就比普通用户更脆弱，所以遇到 XRDP 问题时，优先拿普通用户验证链路，往往更容易定位问题。

2、环境信息

主机：100.4.15.221
操作系统：Ubuntu 22.04.5 LTS
桌面管理器：gdm3 42.0-1ubuntu7.22.04.4
XRDP 版本：0.9.17-2ubuntu3
xorgxrdp 版本：0.2.17-1build1
客户端：macOS Windows App

3、排查前做的备份

远端服务器上已经备份当前可用的远程桌面配置，备份文件路径如下：

/root/rdp-config-backups/ubuntu-rdp-config-20260317_150338.tar.gz

备份内容包括：

/etc/xrdp/xrdp.ini
/etc/xrdp/sesman.ini
/etc/xrdp/startwm.sh
/etc/gdm3/custom.conf
/home/claw/.xsession
/root/.xsession

这个备份非常重要，后续如果再次出现异常，直接和备份文件对比，排障效率会高很多。

4、最终恢复后的可用状态

这台机器最后恢复到可用状态的方式，核心是回退到此前能正常使用的 XRDP 配置风格。

4.1、GDM 固定使用 Xorg

文件：/etc/gdm3/custom.conf

关键配置如下：

WaylandEnable=false

Ubuntu 配合 XRDP 时，Wayland 往往比 Xorg 更容易出现会话异常、黑屏或者登录失败，所以这里明确关闭 Wayland，保持 GDM 走 Xorg。

4.2、XRDP 主配置恢复为历史可用值

文件：/etc/xrdp/xrdp.ini

关键参数如下：

port=3389
security_layer=negotiate
autorun=
allow_multimon=true
max_bpp=32
use_fastpath=both

这一组配置的重点不是“多调几个兼容参数”，而是尽量少改，保持接近之前已经验证可用的状态。最终有效的做法包括：

不强制改成仅 IPv4 监听
不强制设置 autorun=Xorg
不额外压低色深
不关闭 fastpath
不额外做登录绕过类改动

4.3、sesman 恢复本地监听

文件：/etc/xrdp/sesman.ini

关键参数如下：

ListenAddress=127.0.0.1
AllowRootLogin=true

这里最终也回到了更接近默认值的状态，没有继续让 sesman 对外监听。

4.4、startwm.sh 回退到原来的启动方式

文件：/etc/xrdp/startwm.sh

最终可用内容如下：

if test -r /etc/profile; then
    . /etc/profile
fi
exec gnome-session
test -x /etc/X11/Xsession && exec /etc/X11/Xsession

排查过程中，曾经为了强制桌面会话启动方式，修改过 startwm.sh，让它直接走 /etc/X11/Xsession。但最后验证下来，这个改动并不是最终解法，反而是回退到原来的脚本后，连接恢复正常。

5、这次排查得到的几个结论

5.1、XRDP 本身未必真的坏了

从现场现象看，这次并不是 XRDP 服务彻底损坏，而更像是配置漂移叠加 root 图形化登录的脆弱性。

主要依据有两点：

claw 用户此前存在成功的 XRDP 会话记录
回滚掉排查过程中堆上的几项修改后，远程桌面连接恢复

所以，遇到类似问题时，不要一上来就判断为“XRDP 版本太旧必须升级”。

5.2、root 用户远程桌面登录更容易出问题

虽然 sesman.ini 里允许了 AllowRootLogin=true，但这并不意味着 root 就适合作为默认的图形化桌面登录用户。

这次现象非常典型：

普通用户此前有成功登录记录
root 登录更不稳定
强行调 XRDP 兼容参数，反而越改越乱

更稳妥的排查顺序应该是：

先验证普通用户能否成功登录。
普通用户没问题后，再单独确认 root 是否存在额外限制。
如果只有 root 失败，优先怀疑配置漂移或会话启动链路，而不是直接升级软件。

5.3、不要过早过度调优 XRDP

排查过程中，下面这些改动都尝试过，但最终都没有保留：

强制设置 port=tcp://0.0.0.0:3389
强制设置 security_layer=tls
强制设置 autorun=Xorg
强制降低色深并关闭 fastpath
让 sesman 监听 0.0.0.0
自定义重写 startwm.sh
准备从源码升级到 XRDP 0.10.x

这些操作看起来都像“增强兼容性”，但在这次环境里，真正有效的是减少改动、回退到旧配置。

6、macOS 下 Windows App 的连接建议

如果你用的是 macOS 上的 Windows App 连接 Ubuntu XRDP，建议注意以下几点：

遇到异常时，新建一个连接条目，不要一直复用旧缓存
PC name 填服务器地址，例如：100.4.15.221
用户名先用普通桌面用户做验证
不要勾选 Connect to admin session / 连接到管理会话
如果弹出 XRDP 自带登录界面，优先选择 Xorg

这次排查中，客户端缓存状态本身也很可能对结果有影响。

7、必须测试 root 图形化登录时的建议

如果业务上确实要测试 root 的 XRDP 图形化登录，建议按下面顺序来：

先确认普通用户可以正常登录。
确认 /etc/gdm3/custom.conf 中仍然是 WaylandEnable=false。
不要轻易重写 /etc/xrdp/startwm.sh。
如果 startwm.sh 里已经直接 exec gnome-session，就不要默认认为 .xsession 一定会生效。
修改 xrdp.ini、sesman.ini 前先做备份。
如果只有 root 失败而普通用户正常，优先回退配置漂移，再考虑升级 XRDP。

8、后续再次故障时的恢复顺序

如果这台机器以后再次出现 XRDP 连接异常，建议按下面顺序排查：

先确认故障是否只影响 root，还是普通桌面用户也受影响。
检查 /etc/gdm3/custom.conf 中是否仍然保留 WaylandEnable=false。
对比 /etc/xrdp/xrdp.ini、/etc/xrdp/sesman.ini、/etc/xrdp/startwm.sh 与备份 tar 包中的内容。
在 Windows App 中新建一个连接项，并保持 Connect to admin session 为关闭状态。
只有在确认不是配置漂移导致时，再考虑 XRDP 版本升级。

9、备份命令记录

下面是这次在远端主机上使用的备份命令，后续可以直接复用：

backup_dir=/root/rdp-config-backups
stamp=$(date +%Y%m%d_%H%M%S)
mkdir -p "$backup_dir"
backup_tar="$backup_dir/ubuntu-rdp-config-$stamp.tar.gz"

tar czf "$backup_tar" \
  /etc/xrdp/xrdp.ini \
  /etc/xrdp/sesman.ini \
  /etc/xrdp/startwm.sh \
  /etc/gdm3/custom.conf \
  /home/claw/.xsession \
  /root/.xsession

10、总结

这次已经验证有效的恢复方案，不是升级 XRDP，也不是强制 root + XFCE，而是下面这几件事：

保持 GDM 使用 Xorg
把 XRDP 配置文件恢复到之前可用的状态
不走 Windows App 的管理会话模式
使用新的客户端连接条目重新验证

日常使用场景下，普通桌面用户依然是比 root 更稳妥的 XRDP 登录方式。

Ubuntu XRDP root远程桌面排查记录

Ubuntu XRDP root远程桌面排查记录

1、问题背景

2、环境信息

3、排查前做的备份

4、最终恢复后的可用状态

4.1、GDM 固定使用 Xorg

4.2、XRDP 主配置恢复为历史可用值

4.3、sesman 恢复本地监听

4.4、startwm.sh 回退到原来的启动方式

5、这次排查得到的几个结论

5.1、XRDP 本身未必真的坏了

5.2、root 用户远程桌面登录更容易出问题

5.3、不要过早过度调优 XRDP

6、macOS 下 Windows App 的连接建议

7、必须测试 root 图形化登录时的建议

8、后续再次故障时的恢复顺序

9、备份命令记录

10、总结

CATALOG

FEATURED TAGS

FRIENDS