SSH 终端出现 systemd OSC 3008 乱码：两种简单处理办法

用 SSH 连接 Ubuntu、Kubuntu 或其他 systemd 较新的 Linux 系统时，有时会在命令提示符附近看到一串奇怪的控制字符，常见关键词包括 OSC 3008、systemd context、__systemd_osc_context_*。它通常不影响命令执行，但会污染终端显示，复制日志时也容易夹带乱码。

这个问题不一定只和某一个 SSH 客户端有关。WindTerm、某些嵌入式终端、旧版本终端模拟器，或者对 OSC 序列支持不完整的客户端，都可能把本该被终端解释的控制序列直接显示出来。

根因通常是：远端系统在 Bash 环境里加载了 systemd 的 OSC 上下文钩子，而当前 SSH 客户端没有正确处理这些序列。处理思路也很直接：确认这些钩子函数存在后，把它们覆盖成空函数，并清空 PS0。

下面给两个办法。第一个写在远端 ~/.bashrc，适合想一劳永逸处理 SSH 会话的服务器；第二个写在 SSH 客户端的“登录后执行命令”里，适合只想对某个客户端或某个会话生效的场景。

方案一：在 .bashrc 里按 SSH 会话拦截

这个方案的逻辑是：只要检测到当前是 SSH 远程会话，并且系统里确实存在 systemd 注入的 OSC 钩子函数，就把相关函数覆盖成空函数，同时清空 PS0。

把下面这段加到远端服务器的 ~/.bashrc 末尾：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# 检测到 SSH 连接时，拦截 systemd OSC 3008 等终端控制序列乱码
if [[ -n "$SSH_CLIENT" || -n "$SSH_TTY" || -n "$SSH_CONNECTION" ]]; then
    # 仅当系统确实加载了 systemd 的 OSC 函数时才重写，避免污染正常环境
    if declare -f __systemd_osc_context_precmdline >/dev/null; then
        __systemd_osc_context_precmdline() { :; }
        __systemd_osc_context_common() { :; }
        __systemd_osc_context_escape() { :; }
        PS0=""
    fi
fi

保存后重新登录 SSH，或者在当前 shell 里执行：

1

source ~/.bashrc

如果乱码来自 systemd 的 OSC 钩子，重新进入 shell 后通常就会消失。

如果还想兼容特定客户端

有些客户端会设置自己的环境变量，比如 WindTerm 可能有 TERM_PROGRAM=WindTerm。如果你想保留这个判断，也可以写成更宽一点的版本：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# 检测到 WindTerm 或 SSH 连接时，拦截 systemd OSC 3008 等终端控制序列乱码
if [[ "$TERM_PROGRAM" == "WindTerm" || -n "$SSH_CLIENT" || -n "$SSH_TTY" || -n "$SSH_CONNECTION" ]]; then
    # 仅当系统确实加载了 systemd 的 OSC 函数时才重写，避免污染正常环境
    if declare -f __systemd_osc_context_precmdline >/dev/null; then
        __systemd_osc_context_precmdline() { :; }
        __systemd_osc_context_common() { :; }
        __systemd_osc_context_escape() { :; }
        PS0=""
    fi
fi

普通 SSH 场景下，单纯判断 SSH_CLIENT、SSH_TTY、SSH_CONNECTION 已经够用。加上 TERM_PROGRAM 只是为了覆盖某些客户端自己的识别方式。

为什么这个写法相对安全

这段配置有两层限制。

第一层是会话判断：

1

[[ -n "$SSH_CLIENT" || -n "$SSH_TTY" || -n "$SSH_CONNECTION" ]]

这些变量通常只在 SSH 登录会话里出现，所以它主要影响远程登录，不会随便改动本地桌面终端。

第二层是函数存在性判断：

1

declare -f __systemd_osc_context_precmdline >/dev/null

这是一道保险。只有当前 shell 已经加载了 __systemd_osc_context_precmdline 这个函数，才会继续覆盖相关函数。如果系统没有这套 systemd OSC 逻辑，这段配置不会做多余动作。

真正被覆盖的是这几个函数：

1
2
3
4

__systemd_osc_context_precmdline() { :; }
__systemd_osc_context_common() { :; }
__systemd_osc_context_escape() { :; }
PS0=""

它们的作用是让相关钩子不再输出内容。PS0 是 Bash 在读取命令后、执行命令前展开的提示符变量，某些 OSC 序列正是通过它或类似机制插进去的，所以这里也一起清空。

方案二：放到 SSH 客户端的登录后命令里

如果你不想改远端服务器的 ~/.bashrc，可以把修复动作放到 SSH 客户端的“登录后执行命令”里。很多终端或 SSH 客户端都有类似功能，名字可能叫：

1. Command executed after authentication
2. Post-login command
3. Remote command after login
4. 登录后执行命令

填入下面这一行：

1

__systemd_osc_context_precmdline() { :; }; __systemd_osc_context_common() { :; }; __systemd_osc_context_escape() { :; }; PS0=""

如果客户端要求自动执行后换到新的提示行，可以在末尾按它的语法追加换行。例如 WindTerm 的 Command executed after authentication 里，可以使用：

1

__systemd_osc_context_precmdline() { :; }; __systemd_osc_context_common() { :; }; __systemd_osc_context_escape() { :; }; PS0="" \n \n

这里的两个 \n 用来让客户端执行清理命令后再进入新的提示行。这个写法适合 WindTerm 这类支持认证后自动执行命令的客户端，在 Kubuntu 24.04 环境里测试可用。

这种方案的好处是影响范围小：只有使用该客户端、该会话连接时才会执行清理命令，服务器上的 shell 配置不需要改。

两种方案怎么选

如果这台服务器主要是你自己用，或者你希望所有 SSH 客户端连进来都不再看到这类乱码，推荐用方案一。写进 ~/.bashrc 后，换 WindTerm、Windows Terminal、Tabby、Xshell 或其他 SSH 客户端，都能统一处理。

如果服务器是多人共用，或者你只想让某个客户端规避这个问题，推荐方案二。它不改远端配置，也不会影响其他人的 shell 环境。

也可以先用方案二验证问题确实能解决，再决定要不要把方案一写进服务器的 ~/.bashrc。

注意事项

这两个方案只是屏蔽 systemd 的 OSC 输出钩子，不会修改 systemd 服务，也不会影响 SSH 登录本身。

不过，如果你正在使用支持 OSC 3008 的现代终端，并且依赖它显示命令上下文、工作目录或系统状态，那么屏蔽后这些增强提示可能会消失。普通 SSH 运维、开发机登录、服务器管理场景通常不受影响。

另外，不建议一上来就把这类函数覆盖写到全局 /etc/bash.bashrc。除非你确认整台机器所有用户都需要这个行为，否则个人环境优先放 ~/.bashrc，客户端定向修复优先放 SSH 客户端的登录后命令。

简短结论

如果 SSH 连接 Linux 后出现 systemd OSC 3008 乱码，可以按这个顺序处理：

1. 不想改服务器：在 SSH 客户端里设置登录后执行清理命令。
2. 自己的服务器：把 SSH 会话拦截逻辑写进 ~/.bashrc。
3. 多人共用服务器：先用客户端方案验证，再决定是否推广到 shell 配置。

核心就是一句话：只在 SSH 会话里检查 systemd 的 OSC 钩子函数，存在就覆盖为空函数，并清空 PS0。这样能压住乱码，又尽量不影响正常终端环境。