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

admin 2026-10-22 06:36:50 网络安全文章 来源:ZONE.CI 全球网 0 阅读模式

cover_image

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控制序列" 网络安全文章

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

文档分析了旧版SecureCRTSSH登录Ubuntu26时终端显示OSC控制序列乱码的问题,指出这是Ubuntu24.04+默认启用终端ShellIntegration所致。提供了服务端解决方案:通过修改\\~/.bashrc或创建/etc/profile.d/99-disable-osc3008.sh文件清理PROMPT_COMMAND环境变量,并说明pam_systemd.so导致的残留OSC序列可通过修改PAM配置或设置TERM=dumb临时解决。
折扣逻辑漏洞" 网络安全文章

折扣逻辑漏洞"

作者发现Stripe支付平台的手续费减免接口存在并发逻辑漏洞,通过TurboIntruder工具发送30次请求即可重复获取20,000美元优惠额度,实际获得600,000美元减免(远超单次限额)。漏洞无需竞态条件,仅需有效fdo\\_ID即可重复调用接口。文章提供攻击请求示例和脚本代码,属于高价值业务逻辑漏洞。
OpenAI工程师:一天烧不完10亿Token就是失职,禁止手写代码后,我们的人均PR从3.5个涨到了70个。" 网络安全文章

OpenAI工程师:一天烧不完10亿Token就是失职,禁止手写代码后,我们的人均PR从3.5个涨到了70个。"

OpenAI工程师RyanLopopolo提出HarnessEngineering方法,核心是通过管理Agent的上下文和工具实现代码自动化生成。团队禁止手写代码后人均PR从每周3.5个提升至70个,工程师角色转向系统设计、规则制定和业务决策。关键发现包括代码变为一次性产物、SPEC成为核心资产,以及信任建立需通过自动化反馈机制。可操作建议是将开发重点从代码实现转向需求明确化和验收标准细化。
BruceSchneier:我们已打开AI潘多拉魔盒" 网络安全文章

BruceSchneier:我们已打开AI潘多拉魔盒"

本文讨论Anthropic公司FableAI模型被美国政府列为危险军火事件,指出AI能力持续提升带来的安全挑战不仅在于模型本身,更在于控制AI的`马具`系统。关键发现包括开源社区已能用更小模型配合复杂马具复制高级AI的漏洞发现能力,且AI的`无情主动`特性可能导致意外危害。建议推动AI公共选项、资助开源马具和模型以提高透明度,强调需要全球协作应对这一物种级挑战。
评论:0   参与:  0