文章总结： 文档分析了旧版SecureCRTSSH登录Ubuntu26时终端显示OSC控制序列乱码的问题，指出这是Ubuntu24.04+默认启用终端ShellIntegration所致。提供了服务端解决方案：通过修改~/.bashrc或创建/etc/profile.d/99-disable-osc3008.sh文件清理PROMPTCOMMAND环境变量，并说明pamsystemd.so导致的残留OSC序列可通过修改PAM配置或设置TERM=dumb临时解决。 综合评分： 72 文章分类： 应用安全,终端安全,安全工具,解决方案,其他

19.12 用旧版SecureCRT登录Ubuntu遭遇OSC控制序列

原创

沈沉舟 沈沉舟

青衣十三楼飞花堂

2026年6月17日 10:59 北京

在小说阅读器读本章

去阅读

https://scz.617.cn/unix/202606162238.txt

Q:

用旧版SecureCRT SSH登录Ubuntu 26后，bash中总能看到类似下面这种信息

08;
start=2fca083b-a593-404c-8570-0dabd6441acf;
machineid=ebc7387fc82944d6ba9dbe5b8470e471;
user=scz;
hostname=Ubuntu-26;
bootid=bc81f634-419d-4443-a6c5-927297e02283;
pid=00000000000000007613;
type=command;
cwd=/home/scz

这是哪来的？

A: scz 2026-06-16

这不是PS1提示符内容，而是终端Shell Integration的OSC控制序列被错误地显示出来。这些OSC(Operating System Command)控制序列，用于告诉支持OSC的终端某些信息，比如

. 用户 . 主机名 . 当前目录

新版Ubuntu(24.04以后)默认启用了这套机制，某些SSH客户端或终端模拟器不支持这些OSC序列，就将原始内容直接显示出来。

正经解决办法是升级客户端、终端模拟器，使之支持OSC序列。但会遇上不想、不便升级的情形，此时只能从服务端解决，即不要发送OSC序列。

先找出发送OSC序列的源头

(略)

罪魁祸首应该是80-systemd-osc-context.sh，而非vte-2.91.sh。

解决办法之一

vi ~/.bashrc (针对普通用户)

在尾部增加

if [[ -n "$SSH_CONNECTION" ]]; then
    PROMPT_COMMAND=(
        "${PROMPT_COMMAND[@]/__systemd_osc_context_precmdline}"
    )
    PS0=
fi

之后，SSH登录时不再发送OSC序列，同时不影响XWindow桌面里的终端模拟器。上例也可检查”$SSH_TTY”变量。但这样对付不了”su -“情形，原因很显然。

若确实不需要OSC序列，全局禁用最省事。比如

vi /etc/profile.d/99-disable-osc3008.sh

PROMPT_COMMAND=(
    "${PROMPT_COMMAND[@]/__systemd_osc_context_precmdline}"
)
PS0=

创建99-disable-osc3008.sh，它将在80-systemd-osc-context.sh之后执行，会清理两个环境变量。这样做，将极大减少OSC序列，但未彻底解决。”su -“进去的一瞬间，仍有一次OSC；exit离开”su -“时，也有一次OSC。

$ su -
Password:
08;start=275368b7e16e43eeb5d78f9b8f93c233;user=scz;hostname=Ubuntu-26;machineid=ebc7387fc82944d6ba9dbe5b8470e471;bootid=bc81f634419d4443a6c5927297e02283;pid=12539;pidfdid=10420;comm=su;targetuser=root;type=session

# exit
logout
08;end=275368b7e16e43eeb5d78f9b8f93c233

这两次OSC不是bash发送的，而是pam_systemd.so发送的，没有配置文件改变此行为。

$ strings /usr/lib/x86_64-linux-gnu/security/pam_systemd.so | grep ";type=session"
;type=session

可以

vi /etc/pam.d/common-session

注释掉下面这行

#session        optional        pam_systemd.so

这将消除”;type=session”所属的OSC序列，但有其他隐患，不细说。若只是自己的虚拟测试环境，问题不大。

若不想动pam_systemd.so，另一种临时解决办法是

export TERM=dumb
su -

或

TERM=dumb su -

将TERM从vt100或其他值改成dumb，可消除所有OSC序列，但对vi之类的工具有影响，临时应急可以，非长久之计。可以

vi ~/.bashrc (针对普通用户)

alias su='TERM=dumb su'

vi /root/.bashrc

if [ "$TERM" = "dumb" ]; then
    export TERM=vt100
fi

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：青衣十三楼飞花堂 沈沉舟 沈沉舟《19.12 用旧版SecureCRT登录Ubuntu遭遇OSC控制序列》