1. 先弄清楚 SSH ControlMaster 到底在省什么
只要你的日常工作离不开远程登录，就一定经历过这种场景：往一批机器上推配置，脚本循环一百次，每次都要重新握手、重新协商加密、重新做一次公钥签名验证，光标闪一下、再闪一下，两个钟头过去了。很多人第一反应是"网络慢""机器卡"，但真正被浪费掉的，其实是每条连接都要从零开始的那套建连开销。SSH ControlMaster 这个功能就是冲着这笔开销来的——它把第一条连接留下的通道复用给后续所有会话，后面的登录不再走完整的握手与认证流程。
说得再直白一点：没有它的时候，你每敲一次ssh host，等于给远端的门卫重新出示一次身份证、重新核对一次印章、重新配一把一次性钥匙；有它之后，第一个会话把门推开并留了个门缝，后面的会话直接从门缝走进去。功能本身不复杂，~/.ssh/config里三四行就配完了，但配错、配歪、配出隐性故障的人非常多，原因在于它的三个参数彼此耦合，再加上 Unix domain socket 的路径长度、文件权限这些容易被忽略的细节，一不留神就会出现"时灵时不灵"的状态。
这篇文章面向的是已经会用 SSH、但还没系统吃过这口红利的人。我会把原理、参数、配置模板、实测数据、踩坑清单、安全边界一条条摊开讲，你可以直接照着抄作业；已经在用的人，也能从后面的排查章节里捞到几条平时搜不到的判定思路。
2. 一次 SSH 连接的时间都花在哪了
2.1 完整建连的六个阶段与 RTT 放大效应
要理解复用的价值，得先知道不复用的时候时间去了哪儿。一条 SSH 连接从敲下回车到出现提示符，大致要经过：DNS 解析、TCP 三次握手、协议版本交换与算法协商（KEX）、密钥交换（Diffie-Hellman 或 ECDH 这一轮通常要跑一到两个来回）、用户认证（公钥签名验证或密码）、会话通道建立与 PTY 分配。其中 TCP 握手占一个往返，协议与算法协商占一个往返，密钥交换至少占一到两个往返，认证再占一个往返，加起来通常落在四到六个网络往返时延这个区间。
关键点在于"往返"这个词。同城机房 RTT 两毫秒，这点开销你根本感觉不到；但如果你是从办公室连跨区域机房、从移动网络连云端主机、或者从境内连海外节点，RTT 动不动就是几十毫秒到两百毫秒，四到六个往返就是半秒到一秒多的纯等待。而且 TCP 还有慢启动，新连接的初始拥塞窗口很小，第一个数据包的传输效率天然吃亏——这在传输大文件时感受尤其明显。
我在一次内部分享里做过一个粗糙的测算：RTT 一百五十毫秒的链路上，一条 SSH 连接从发起到可交互大约三秒出头，其中真正用于加密计算和身份验证的时间不到两百毫秒，剩下全是等网络来回。这意味着超过九成的建连时间是在等，而不是在算。对单次登录来说，三秒忍了；对循环一百次的批量任务来说，就是五分钟的纯浪费。
2.2 复用的核心思路：一条通道跑多条会话
ControlMaster 的做法是在客户端侧做一层"通道代理"。第一次连接时，SSH 客户端在本地创建一个 Unix domain socket 文件（默认放在~/.ssh/下，你也可以指定到/run/user/之类的位置），并在后台留下一个主连接进程。这个主进程持有已经完成握手和认证的 TCP 连接和加密上下文。此后你每一次登录同一台目标机，SSH 客户端会先检查这个 socket 文件在不在、能不能连上，能连上就不再做 DNS、握手、KEX、认证这一整套动作，而是直接通过本地 socket 告诉主进程："给我开一条新会话通道。"
主连接和会话通道的关系，用打电话类比最贴切：老办法是每说一句话就挂断重拨，ControlMaster 是先拨通一次，之后所有对话都在这通电话里进行，谁想说谁接麦。加密通道只有一条，但里面可以并行跑很多条逻辑通道，每条终端、每条端口转发、每条scp传输各自独立，互不干扰。
这里有个容易被误解的点：复用的粒度是"客户端到目标主机"这个组合，不是全局。你连 A 机器和连 B 机器，各自有各自的主连接；你用不同的用户名连同一台机器，也是两条不同的主连接；端口不同，同样是两条。这个粒度设计是对的，因为认证上下文和会话密钥本来就按目标区分的。但也意味着你不能指望"开了一个 master 就所有机器都变快"，批量场景下每台目标机都需要自己的第一条连接。
2.3 哪些场景该开，哪些场景开了反而添乱
并不是所有场景都适合无脑打开。我整理了一张对照表，判断标准就一条：同一目标机在短时间内是否会被反复连接。
| 场景 | 是否推荐 | 原因 |
|---|---|---|
| 交互式多窗口登录同一台机器 | 强烈推荐 | 开五个终端只付一次建连成本 |
| 批量推送文件、批量执行命令 | 强烈推荐 | 收益随机器数量线性累积 |
频繁调用scp/rsync的小文件同步 | 推荐 | 每次传输省一次完整握手 |
| 编排工具反复调用 ssh | 推荐 | 很多工具内部已默认启用同类机制 |
| 一天只登一次的单台机器 | 可选 | 收益有限，但也没坏处 |
| 多用户共享同一台跳板机 | 需要额外隔离 | socket 路径必须按用户区分 |
| 需要频繁切换身份/密钥的场景 | 慎用 | 复用后新密钥不会重新生效 |
| 目标机侧有严格会话审计要求 | 慎用 | 多条会话复用同一连接，审计侧看到的是一条 |
最后两行值得多说两句。认证复用意味着主连接建立之后，你换IdentityFile、换ProxyCommand、甚至改~/.ssh/authorized_keys的权限，对已经存在的 master 都不起作用——它认的是当初那份凭证。很多"我明明换了密钥怎么还登得进去"的困惑，根源就在这里。解决办法只有一个：ssh -O exit <目标>把主连接显式关掉，再重新连。
3. 三个核心参数的工作机制与配置方法
3.1 ControlMaster 的四种取值，以及 ask 到底怎么用
ControlMaster控制的是"当前这条连接要不要扮演主连接的角色"，取值有no、yes、ask、auto四种。no是关闭，等价于不用这个功能；yes是无条件创建主连接并后台驻留；auto是最常用的——如果本地已经存在可用的 socket 就复用它，不存在就顺手创建一个，行为最"聪明"，你不需要关心当前是第几次连接。
ask比较特殊，它会在创建主连接之前弹出一个确认（需要终端可交互或者配置了SSH_ASKPASS），常用于共享环境或者你不想让后台进程悄无声息地跑起来的场合。实际用的人不多，因为在脚本里它基本会卡住——没有 tty 的时候行为不可预期，我建议只在个人工作站上做"临时试探"时用。
配置层面，命令行参数-M等价于-o ControlMaster=yes，临时调试很方便。写进配置文件时通常是这么一套最小组合：
# ~/.ssh/config Host * ControlMaster auto ControlPath ~/.ssh/cm/%C ControlPersist 10m这三行是绝大多数人真正需要的东西，Host *表示对所有目标生效。注意第一行的auto而不是yes——用yes的话，你每次连一台新机器都会强制留一个后台进程，长时间下来ps里会堆出一串没人管的 ssh 进程。
3.2 ControlPath 的命名规则与那条 104 字节的硬线
ControlPath指定 socket 文件放在哪儿、叫什么名字。最省心的写法是%C，它由 OpenSSH 内部生成一个哈希值，等价于对%l%h%p%r（本地主机名、目标主机、端口、用户名）做 SHA1 后取前若干位。这个写法的好处有两个：一是自动区分不同目标、不同用户、不同端口，不会互相覆盖；二是长度固定且短，不容易触发路径超限。
如果你不用%C，也可以手工拼占位符，比如~/.ssh/cm/%r@%h:%p。可读性更好，一眼能看出这条 socket 对应哪台机器，排查时方便。但它有个致命隐患：Unix domain socket 的路径长度是有硬上限的。Linux 上sun_path是 108 字节，BSD 和 macOS 更紧，只有 104 字节。注意这是完整路径的字节数，包括~展开后的绝对路径。当路径超限时，你看到的报错长这样：
unix_listener: path "/home/somebody/.ssh/cm/user@very-long-hostname.internal.example:22.abc123" too long for Unix domain socket这个报错信息本身还算清楚，但它经常被淹没在-v的一堆输出里，很多人只看到"连不上"就放弃了。我在早期踩过一次更隐蔽的：路径没超，但~展开后的家目录特别深，加上用户名长，正好卡在边界上，某些目标能连、某些不能，排查了半天才发现是长度问题。从那以后我一律用%C，或者把目录挪到/run/user/$(id -u)/cm/这种短路径下。
注意：
%C需要 OpenSSH 6.7 及以上版本。老版本上不认这个占位符，会原样当成目录名，表现是路径里真出现一个%C目录，然后就卡在超限报错上。
3.3 ControlPersist：后台驻留多久才算合理
ControlPersist管的是主连接在最后一个会话关闭之后还能活多久。取值可以是yes（无限期，直到显式关闭）、no（会话结束就退，等于没驻留）、0（会话结束后立即退出，但连接本身复用逻辑仍然生效）、或一个时间值如30s、10m、2h。
这个参数是收益和风险的分界线。时间设太短，比如5s，你关掉窗口再开一个，master 可能已经退出了，白配；设太长，比如yes，后台会长期挂着一个持有有效认证的进程，机器被人碰到或者你自己忘了清理，都是隐患。我的经验值是：
- 交互式日常登录：
10m到30m，够你来回切窗口，又不会挂一整天。 - 脚本/批量任务：任务开始前显式建立 master，任务结束后
ssh -O exit立刻关掉，配置里给个5m兜底即可。 - 持续集成环境：给
30s到1m，任务跑完就让它自然退出，避免多个流水线共用残留连接。
还有一个容易忽略的细节：ControlPersist只有在ControlMaster启用（yes或auto）时才有意义。单独写一行ControlPersist 10m而ControlMaster是no，这行配置等于注释。
3.4 一条连接从建立起复用的完整时序
把这几个参数串起来看，一次带复用的连接生命周期大致是这样：
第一步，你执行ssh host。客户端解析配置，命中Host规则，发现ControlMaster auto且ControlPath指向的 socket 不存在。于是走完整建连流程：DNS、TCP、KEX、认证，全部照常。
第二步，认证通过后，客户端在ControlPath指定的位置创建 socket 文件，并 fork 出一个后台的 master 进程持有这条连接。你当前这个会话，本质上是通过这个 socket 与 master 进程通信的一个通道。
第三步，你关掉终端。你的会话通道关闭，但 master 进程不退出，它按照ControlPersist的设置开始计时。此时你ps aux | grep ssh能看到一个类似ssh: /home/xxx/.ssh/cm/xxxx [mux]的进程。
第四步，你再开一个终端连同一台机器。客户端发现 socket 存在，尝试连接，握手成功——这一步只花本地进程间通信的时间，通常几十毫秒——然后请求开一条新通道。全程没有网络往返。
第五步，所有会话都关掉之后，计时器到点，master 进程退出，socket 文件被删除。如果中途你执行了ssh -O exit host，则立即退出，不等超时。
理解了这个时序，"为什么有时候复用没生效"就有判断依据了：要么 socket 没创建出来（权限、路径、配置未命中），要么创建了但连不上（残留文件、权限不对），要么连上了但被拒绝（版本不匹配、主进程已死）。
4. 分场景配置模板与工具链配合
4.1 三套可直接抄的配置
下面三套配置覆盖了我遇到的绝大部分需求，你可以按需取用。
第一套：个人工作站通用配置。
Host * ControlMaster auto ControlPath ~/.ssh/cm/%C ControlPersist 30m ServerAliveInterval 30 ServerAliveCountMax 3ServerAliveInterval这两行不是必须的，但它和复用搭配得很好：长驻的连接如果中途网络抖动断了，没有心跳探测的话，master 进程会一直以为自己还活着，后续会话连上去之后一片死寂。加上心跳，断了能被及时发现。
第二套：批量运维专用配置。单独定义一个主机组，走单独的 socket 目录，避免和日常登录的 master 混在一起：
Host batch-* ControlMaster auto ControlPath /run/user/%i/cm/%C ControlPersist 5m BatchMode yes StrictHostKeyChecking accept-new注意ControlPath里的%i是本地用户 ID，/run/user/<uid>/是各发行版都有的用户级运行时目录，路径短、权限天然隔离、重启自动清理，比塞在~/.ssh下干净得多。用之前记得先mkdir -p /run/user/$(id -u)/cm。
第三套：跳板中转场景。如果你的实际路径是"本地 → 跳板 → 目标"，那么复用要配在跳板这一段和本地到跳板这一段两处：
Host jump HostName 10.0.0.10 User ops ControlMaster auto ControlPath ~/.ssh/cm/%C ControlPersist 10m Host target-* ProxyJump jump ControlMaster auto ControlPath ~/.ssh/cm/%C ControlPersist 10mProxyJump之后，客户端到跳板的连接由 ControlMaster 复用，跳板到目标的连接每次新建——这是 SSH 的固有结构决定的，除非你在跳板机上也部署一套复用配置并让ssh从跳板上发起。实际经验是：跳板段的复用收益最大，因为那一段往往是跨网络的，RTT 最高；跳板到内网目标通常只有几毫秒，复用与否差别不大。
4.2-O系列控制命令：管理 master 的正确姿势
配置好之后，你需要一套命令来查看和操控主连接，否则就只能等超时。这几个命令是我每天都要用的：
# 检查某个目标的主连接是否还在，会输出 "Master running (pid=xxxx)" ssh -O check target-host # 立刻关闭主连接，socket 文件同时删除 ssh -O exit target-host # 停止接受新会话，等现有会话结束后退出 ssh -O stop target-host # 在已有连接上开一条转发，不新建连接 ssh -O forward -L 8080:127.0.0.1:80 target-host # 取消上一条转发 ssh -O cancel -L 8080:127.0.0.1:80 target-host-O forward和-O cancel这两个平时被提得少，但很实用。比如你在写一个测试脚本，需要临时把目标机上的服务映射到本地端口，又不想为这一条转发付一次完整握手，就可以先建立 master，再用-O forward添加转发，用完-O cancel撤掉，全程一条连接。
-O stop在滚动发布场景里特别好用：你想让老连接跑完手上的活、但不再接受新的会话，用stop而不是exit，就不会把正在跑的任务掐断。
还有一个排查小技巧：ssh -O check的返回值可以直接用在脚本里做判断，退出码为 0 表示主连接健康，非 0 表示不可用。批量脚本里可以先 check 一下，不健康就重建，比盲连更可控。
4.3 与常见工具链的配合方式
文件同步类。scp和rsync都走 SSH 传输层，所以只要它们读取同一份~/.ssh/config，复用自动生效。rsync有个额外注意点：它默认可能走自己的 SSH 调用方式，需要确认-e ssh用的就是系统ssh，而不是某个打包版本。我遇到过一次rsync完全不享受复用的情况，最后发现是某工具链里捆绑了一个独立编译的 ssh，读的配置文件路径不一样。
版本控制类。git通过GIT_SSH_COMMAND或者core.sshCommand调用 ssh。配置了复用之后，连续多次git fetch会明显变快，尤其是在高延迟链路上。如果你的仓库数量多、每次拉取都要建连，这个收益比想象中大。
批量编排类。不少批量运维工具内部已经内置了连接复用机制，只是以它自己的参数名出现（比如某个开关叫"连接持久化"或者"pipelining 相关配置"）。这些内置机制和你在~/.ssh/config里配的 ControlMaster 可能同时生效，也可能互相打架——具体表现是 socket 文件数量异常增长，或者连接莫名其妙超时。我的做法是：只保留一层机制。用工具自带的那层，就把配置文件里的ControlMaster关掉；用 SSH 层，就去工具里把相关开关关掉。两边都开不会崩，但排查问题时你会多花一倍时间。
远程开发类。各类编辑器插件、远程开发模式底层都是反复调 ssh。这类工具往往自己维护一套连接池，和 ControlMaster 叠在一起通常没坏处，但如果你发现"改了配置重启编辑器还是连不上"，多半是它的连接池里还挂着老的 master，需要把编辑器彻底退出或者清理它的缓存目录。
5. 实测数据：复用到底能省多少
5.1 测试方法说明
下面的数据来自我在一台普通办公笔记本上做的对照测试，不是严格基准，只用来判断量级。方法是：对同一批目标机分别执行"不复用"和"复用"两组命令，每组重复五轮取中位数，中间机器负载和网络条件尽量保持一致。目标机分布在三个不同延迟区间，每组二十台。数据仅供你判断自己场景下的收益预期，不构成任何性能承诺。
| 链路 RTT | 不复用单次建连 | 复用后单次会话建立 | 降幅 |
|---|---|---|---|
| 约 8 ms（同城） | 0.18 s | 0.03 s | 约 83% |
| 约 45 ms（跨区域） | 0.62 s | 0.05 s | 约 92% |
| 约 150 ms（跨地域） | 1.85 s | 0.09 s | 约 95% |
看这张表有一个反直觉的地方：绝对收益最大的是高延迟链路，但相对收益最大的其实是中间那档。同城链路因为本来就不慢，复用省下的绝对值只有一百多毫秒，日常操作几乎无感；而跨地域链路虽然省得多，但你本来对"慢"有心理预期。真正让人觉得"怎么突然都这么跟手"的，是那种三十到六十毫秒的中等延迟——单次感觉不明显，连着操作一百次就完全不一样了。
5.2 批量任务的收益测算
把上面的单次数据乘上任务规模，效果就触目了。假设你有两百台目标机，每台执行一条耗时约 0.2 秒的查询命令，串行执行：
- 不复用，RTT 45 毫秒档：两百乘以 0.62 秒，约 124 秒，其中真正执行任务的时间只有 40 秒，剩下 84 秒全在建连。
- 复用后：两百乘以 0.05 秒加上执行时间，约 50 秒，整体耗时砍掉六成，且其中建连开销从 84 秒降到 10 秒。
这个账还有一层：上面的串行执行其实是最差情况。实际做批量任务都会并发，但并发数一高，建连阶段的 CPU 占用和加密计算开销就成了瓶颈——每一条新连接都要做一次密钥交换，这在低配机器上很吃 CPU。复用之后，加密计算只在第一批连接上发生，后面的会话只是通道切换，CPU 压力骤降。所以复用不只是省时间，某种程度上也是在给执行机减负。
5.3 什么情况下收益接近于零
有必要说清楚反面。如果你连接的是一台和你在同一台机器上的容器（localhost或者127.0.0.1），握手开销本来就微乎其微，配了也看不出区别，反而多出一层 socket 转发的开销。如果你的脚本每次都要用不同用户名、不同密钥去连同一台机器，主连接根本没法复用，配置纯属摆设。如果目标机的 sshd 侧限制了单连接的最大会话数（有些加固模板会设），复用到上限之后新会话会被拒绝，表现是随机失败——这个坑在共享跳板机上尤其容易踩到。
6. 踩坑实录与排查清单
6.1 socket 目录不存在导致的静默失败
这是新手最容易撞的一个。ControlPath ~/.ssh/cm/%C里的cm目录，OpenSSH不会自动帮你创建。目录不存在时，创建 socket 失败，但客户端通常只是在调试日志里嘀咕一句，然后把当前连接正常跑完——表面上你登进去了，实际上根本没有主连接。等你下次再连，仍然走完整握手，你会以为"配了没用"。
判断方法很直接：登录之后看ssh -O check host是不是报No such file or directory，或者手动看ls -la ~/.ssh/cm/里有没有文件。修法就是mkdir -p ~/.ssh/cm && chmod 700 ~/.ssh/cm。权限一定要 700，因为 ssh 对 socket 目录的权限敏感，宽了会拒绝使用。
6.2 残留 socket 与"already exists"报错
进程被强杀、机器休眠唤醒、容器重启，都可能留下一个指向已死进程的 socket 文件。此时你再连，会看到类似这样的提示：
ControlSocket /home/xxx/.ssh/cm/abc123 already exists, disabling multiplexing意思是客户端发现了这个文件，但连不上，于是干脆放弃复用，安静地走完整建连。这条信息通常只出现在-v输出里，不仔细看根本发现不了。处理办法：删掉那个文件即可，或者更稳妥地用ssh -O exit host（如果能识别的话）再补一次删除。
为了少踩这个，我的配置里把 socket 目录指到了/run/user/<uid>/cm，这个目录在重启时会被运行时系统自动清理，残留概率大幅下降。
6.3 权限问题：socket 本身就是一个凭证
Unix socket 文件的权限默认受umask影响。如果umask是宽松的（比如 022），socket 会是其他用户可读的，某些 OpenSSH 版本会因此拒绝使用，或者在启动主连接时报权限错误。表现是建连失败或者复用被跳过。
标准做法是两层保险：目录权限 700，umask在启动 ssh 之前设为 077，或者干脆依赖ControlPath指向只属于你的/run/user/<uid>/。这一点在多人共用同一台跳板机、或者多人共用同一个服务账号时格外关键——能连上那个 socket 的人，等于拥有了你这条已认证的连接，不需要任何密钥就能在目标机上操作。这不是危言耸听，是一个必须认真对待的边界。
6.4 常见问题速查表
| 现象 | 大概率原因 | 排查动作 |
|---|---|---|
| 配了但感觉没变快 | socket 目录不存在 / 配置未命中 | ssh -O check，加-v看是否出现 mux 相关日志 |
报too long for Unix domain socket | 路径超过约 104 字节 | 改用%C，或把目录换到/run/user/ |
报already exists, disabling multiplexing | 残留 socket | 删除对应文件后重试 |
报Permission denied连接 socket | 目录或文件权限过宽 | 目录 700，检查umask |
| 换了密钥还是能登录 | 主连接持有旧凭证 | ssh -O exit后重连 |
| 复用后端口转发失效 | 转发绑定在旧会话上 | 用-O forward重开，或重建 master |
| 批量任务随机失败 | 单连接会话数达上限 | 减少并发，或降低单机复用强度 |
| master 进程越积越多 | ControlMaster yes且无超时 | 改auto加ControlPersist时间 |
6.5 和端口转发、Agent 转发一起用时的注意点
这几样东西共用一条通道时，行为会有点绕。端口转发是绑定在主连接上的：你用普通方式ssh -L建起来的转发，会跟着你那个会话结束而消失，但只要主连接还在，用-O forward加上的转发就能一直留着。这既是便利也是陷阱——我曾经因为一个"看起来还在"的转发其实是挂在某个已经被遗忘的 master 上，调了半天才发现流量根本没走本地端口。
Agent 转发的情况类似：-A打开之后，转发的 agent socket 生命周期跟主连接走，而不是跟你当前的会话走。所以你会看到明明当前会话已经关了，主连接上残留的 agent 转发还能被别人拿去用（如果 socket 权限没管好的话）。多用户环境下的建议是：不要在主连接上开 Agent 转发，需要时单独开一条不复用的连接。
6.6 隔离策略：多用户、多环境的共存
在同一台机器上，如果同时存在多个身份、多个环境（比如生产、测试各一套凭证），必须保证 socket 不串。可靠的隔离方式有三层：路径层按用户和环境分目录（如/run/user/<uid>/cm-prod/、/run/user/<uid>/cm-test/）；配置层用不同Host块指定不同ControlPath；操作层在切换到另一套环境前，先对当前环境的机器执行一次ssh -O exit。
有个细节容易被忽视：同一台目标机，用不同用户名登录，是两个独立的 master。因为%C里包含了用户名。这一点在设计批量脚本时很重要——如果你的脚本一会儿用普通账号一会儿用特权账号，用两个账号交替连同一台机器，实际上是两套连接，谁也不会省谁。
7. 安全边界与规范建议
7.1 复用带来的三个真实风险面
第一是凭证窗口延长。不复用时，一次登录结束，认证上下文就没了；复用时，master 在ControlPersist期间一直持有有效凭证。这段时间里，任何能访问那个 socket 的本地进程（不管是你自己的脚本还是别的什么东西）都能在目标机上开新会话。所以ControlPersist的取值本质上是一个安全参数，不只是性能参数。
第二是审计粒度变化。目标机侧的 sshd 日志里，多条会话复用同一连接时，你可能只看到一条登录记录，后续操作发生在已建立的通道上。如果你的环境对操作留痕有明确要求，这一点必须提前和运维确认，必要的时候用不复用的专用账号来做敏感操作。
第三是残留状态难以察觉。master 是后台进程，不占终端，不留窗口，ps里一行不起眼。人走了连接还在，这在共享工作站上是个实实在在的问题。我的习惯是：离开工位前统一跑一遍ssh -O exit把当前环境的主连接清掉，或者在配置里把ControlPersist压到比午休时间短。
7.2 团队层面的落地规范
个人配好很容易，推广到团队就容易变形。给出我实际用过、效果比较稳的三条规范：
统一 socket 目录位置。所有人用/run/user/<uid>/cm，不要各显神通往家目录不同深度里塞。统一之后，路径超限的问题基本消失，出问题时的排查话术也统一了——"先看那个目录里有没有东西"。
区分交互与批量的ControlPersist。交互式给半小时，批量任务给一分钟且任务结束显式关闭。这条规则最好写进团队的脚本模板里，而不是指望每个人记。
脚本中显式管理生命周期。批量脚本开头建立 master，结尾ssh -O exit，中间所有操作复用这一条。这比依赖超时干净得多，也避免脚本异常退出后留下一堆僵尸主连接。
| 规范项 | 推荐值 | 不这么做的后果 |
|---|---|---|
| socket 目录 | /run/user/<uid>/cm | 路径超限、残留、权限混乱 |
| 交互场景 Persist | 30 分钟左右 | 长期挂起的认证上下文 |
| 批量场景 Persist | 1 分钟以内 + 显式关闭 | 脚本异常后连接堆积 |
| 目录权限 | 700 | 其他本地用户可劫持连接 |
| 密钥轮换 | 先-O exit再换 | 新密钥不生效，误判为配置错误 |
这套东西写下来不复杂，实际执行时最容易破功的是最后一条。团队里做密钥轮换的时候，总有人抱怨"我密钥换了怎么还是登不上"——因为主连接还拿着旧凭证，他换的是新文件，但连接根本没用新文件。把这一条写进轮换流程的检查清单里，能省掉大量沟通成本。
8. 我个人的几点使用体会
这个功能我用了很多年，最大的感受是：它属于那种"平时想不起来,用过之后回不去"的基础设施优化。配置成本只有三行，收益却覆盖了你所有跟远程机器打交道的动作。真正让我踩坑最深的不是功能本身，而是它的失败方式太安静——socket 建不出来、残留文件挡住复用、权限不对被跳过，这些情况都不会阻止你完成当前操作，看日志才能发现。所以我现在养成了一个很小的习惯：新机器第一次配好之后，登录进去立刻敲一次ssh -O check <host>，确认输出里真有Master running，才算配置生效。这一步花两秒钟，能避免后面几个小时的"为什么感觉没变快"。
另一个建议是别把复用开得太满。有人喜欢ControlPersist yes全场景常驻，觉得方便，我觉得不值当——挂着的不是连接，是一份随时可用的访问凭证。给个明确的时间边界，让它在你不注意的时候自己消失，这个取舍我做了很多次，还是觉得划算。批量任务那种需要反复连同一批机器的场景，才是它真正的主场，把力气花在那儿，回报最直接。
