运维老手血泪总结：5大服务器部署深坑

　　2026年8月13号下午三点十七分，我蹲在IDC机柜前，右手捏着根快没电的USB-C线，左手还沾着上个机房蹭来的蓝漆——不是防静电漆，是工人刷柜门时甩的。空调嘶嘶响，冷凝水滴在脚边，第八次插拔那台Dell R750的iDRAC口，屏幕右下角时间跳到三点十九分，远程console还是灰的。

　　我原以为是网线松了，结果发现交换机端口LED灯根本没亮；我原以为是固件卡死，结果用IPMI硬重启后，系统倒起来了，但SSH连不上；我原以为是防火墙规则没生效，结果ssh -v敲到Authentication refused那一行，才看见log里明晃晃写着“no matching key exchange method found”。

　　同事老陈蹲在我斜后方，嚼着半块没吃完的桃酥，油渣掉在机柜导轨上，他突然说：“你试过把sshd_config里KexAlgorithms开头那行删了没？”我没理他——上周刚被他推过一个“修复TLS 1.0兼容性”的Ansible脚本，跑完三台Web节点全挂HTTPS握手，连curl -v都报unknown protocol。反正这事不能听他的。

　　我翻出自己2021年存的配置备份，逐行diff，找到那行被加上的KexAlgorithms：diffie-hellman-group14-sha256,diffie-hellman-group16-sha384——看着就硌硬。删掉，reload，再试，还是拒。我盯着这串字符发了二十来分钟愣，手边那杯咖啡早就凉透了，表面浮起一层皱皱的膜。

　　（二楼保洁阿姨推着水车经过，轮子卡在地板缝里，她骂了句“这破地砖”，又哐当哐当走远）

　　后来我才摸到真正问题：不是服务端配置，是客户那边新换的跳板机，OpenSSH版本升到了9.8p1，默认关掉了所有带sha256以下的密钥交换——而我们所有运维终端的~/.ssh/config里，统一写死了PreferredAuthentications和KexAlgorithms，为了应付三年前某次安全扫描。没人动过那几行，也没人改过文档。就搁那儿，像块锈死的垫片。

文章配图，仅供参考

　　最绝的是，昨天上午备案办下来之前，我们临时启用了旧服务器做DNS兜底，那台老家伙sshd还是OpenSSH_7.4p1，密钥交换算法全开着，所以所有测试、灰度、客服验证全过——连监控告警都没响过一声。等备案一过，流量切过去，新集群暴露在真实终端环境下，才开始连不上。不是故障，是适配断层。

　　我翻出上周三的变更记录表，上面写着“部署完成✅”，签名栏龙飞凤舞：小张。就是那个去年把prod环境NTP源从pool.ntp.org改成自己编译的chrony镜像、结果导致所有日志时间戳飘移四十秒的小张。他现在在隔壁会议室给甲方演示API响应速度，声音隔着两道门都听得清：“……底层稳定性绝对经得起压测。”

　　（我鞋带散了，系的时候发现左脚袜子破了个洞，拇指能顶出来）

　　我也不知道该不该把这事写进故障复盘报告——写了，归因会变成“终端环境差异”，听起来像推诿；不写，下次新人部署照样照抄老配置，一样跪。优胜劣汰？对。但汰掉的从来不是代码，是记性，是那个没点开终端history去查最后一条ssh命令的人，是我自己。

　　有谁碰到过这个吗？

（编辑：航空爱好网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!